CWPSRV backdoor announced in some security websites

[djprmf]

Honestly, Starburst, I don't know why you are still fighting this. This is not a matter of opinion, it's a fact. You can scream that it is false as many times as you like, but that doesn't change reality. We all get things wrong sometimes, myself included. But doubling down on false information just because your ego won't let you admit you misunderstood a report is the worst way to help SysAdmins secure their servers.

Take a step back and read.

You are fundamentally confusing when a security firm privately detects a threat with when they publicly disclose it to the world.

1. Capture Date vs. Public Disclosure
Yes, XLab's internal systems captured the malware sample on June 29. However, they did not publish their findings on June 29. They spent months analyzing it, reverse-engineering the payload, and finally published their report on November 5.

There are no "June CVEs" for this malware because the public literally did not know this specific backdoor, its payload, or its custom Unix sockets existed until the researchers released their paper this week. The threat intelligence is brand new.

2. Updates Do Not Evict Attackers
You keep claiming this is irrelevant because it was "fixed" in newer versions. Patching a vulnerability prevents future exploitation. It does not remove a root-level backdoor that is already installed.

If a server was compromised in August while running 1.24.0, and the admin later updated to 1.30, the backdoor is still there. The attacker already replaced binaries, forged file timestamps, and established persistence. A standard CWP panel update does not perform forensic malware remediation or hunt down rogue hidden sockets.

Claiming a server is "safe" just because the admin updated CWP is like saying a house is safe because you fixed the broken window, while completely ignoring that the burglar is already living in your attic.

The actionable intelligence here is that SysAdmins need to scan their servers today for the ngx_http_integrity_helper socket, regardless of what CWP version they are currently running. If you refuse to grasp this basic concept of incident response and post-exploitation persistence, there is no point in continuing this conversation.

[Starburst]

Only Fact is this information is from JUNE, which even the articles state. NOT November.

And now you are trying to move to another subject about infected servers and updates, which had nothing to do with your first comment (4th post of this thread).

FACT is this is OLD information as I stated in the 3rd comment of this thread, in response to adrianofnatal's post.

Anyone who installed a new server with CWP 1.25.0 or after did not have to worry about this.

[djprmf]

Only Fact is this information is from JUNE, which even the articles state. NOT November.

As the image above from the original XLab security report clearly shows, the article was published on November 5, 2026. The public disclosure happened in November, not June. That is an undeniable fact.

Beyond that, you are now projecting and attempting to rewrite the history of this very thread.

1. "Moving to another subject"
I am not moving to another subject. My original comment was entirely about the fact that updates do not clean infected servers. Let me quote my exact words for you:

"They have been fixed in recent CWP versions, but that doesn't mean that servers haven't been affected - even after they have been patched - by the exploit before the patch was even made."

This has been my core argument since the beginning. You are the one who tried to derail the conversation into a debate about CVE release dates and typos.

2. "Anyone who installed a new server... did not have to worry"
You have just moved the goalposts again. In your first reply, you didn't say "new installations don't have to worry." You said, verbatim:"These are OLD, and have been fixed since 1.25."

Saying an active malware threat is "OLD and fixed" implies the danger is gone. The vast majority of CWP users do not install fresh servers every month; they run existing infrastructure. If an admin updated their existing server to 1.25.0, they are still compromised if they were hit in June, August, or September. Telling them the threat is "old and fixed" gives a false sense of security and is outright dangerous advice.

The threat intelligence and the IoCs (Indicators of Compromise) needed to detect this backdoor were only published to the public this week. That makes the actionable information brand new.

Since you are now ignoring the core security issue just to argue semantics about the word "new", this conversation has stopped being productive

[Starburst]

Just looked, notifications started being sent out in May & June 2026 about issues in Nginx, Apache and OpenSSH.

So June 29th in the articles is about right for 3rd party sites to start publishing.

[djprmf]

At this point, you are just throwing completely unrelated things against the wall to see what sticks.

General security notifications about Nginx, Apache, or OpenSSH from May and June have absolutely nothing to do with a targeted malware campaign against Control Web Panel.

The June 29th date in the XLab report isn't about "3rd party sites publishing" generic Nginx issues. The report explicitly states that June 29th is the exact day their Threat Intelligence system captured a specific malicious bash script (cwpsrv_update.sh) downloading a custom-compiled trojan from a specific threat actor IP (136[.]0.141.71).

CWPdoor is not a generic Apache or OpenSSH bug. It is a custom backdoor built specifically to replace the cwpsrv binary and hide its tracks.

You went from demanding a November CVE number, to arguing the XLab article was published in June, and now you are trying to link generic OpenSSH bugs to a targeted CWP malware script. You are digging a deeper hole just to avoid admitting you misread the original report and its publication date.

I have already provided the facts, the actual publication dates, and the actionable IoCs for anyone who actually wants to secure their infrastructure. You can keep grasping at straws if you want

[Starburst]

You are funny @djprmf

Now Read UNDER the graphic below the that title, and it says:

On June 29, 2026, the XLab's Cyber Threat Insight and Analysis System(CTIA) captured a suspicious script named cwpsrv_update.sh. The script downloads a file named cwpsrv from the remote server 136.0.141.71 and replaces the file of the same name on the system. Our analysis confirmed that the downloaded cwpsrv is a passive backdoor that can be triggered by specific headers in HTTP/HTTPS traffic to remotely execute commands specified by the attacker. Since it targets Control Web Panel, we named it cwpdoor.

What is the date after the first word...

I'll help...

June 29, 2026

[djprmf]

You are literally proving my exact point for me, and you don't even realize it.

Please read the sentence you just quoted, very slowly: "XLab's Cyber Threat Insight and Analysis System(CTIA) captured a suspicious script".

It says their internal threat system captured the malware on June 29. It does not say they published the article to the public on June 29.

Let me give you a very simple analogy, since you are struggling to separate these two concepts:
If a journalist records a video on June 29, but doesn't broadcast it on television until November 5... when did the public find out about it? November 5.

1. XLab captured the malware in June.
2. They spent months reverse-engineering the payload.
3. They published the article, publicly disclosing the threat to the world, on November 5.

My original post stated: "They have been publicly disclosed yesterday." Because the article was published on November 5, my statement is a 100% accurate, undeniable fact.

At this point, you aren't arguing with me about server security anymore. You are arguing with the dictionary definition of the word "published". I can explain the difference between a malware capture date and a whitepaper publication date to you, but I cannot understand it for you.

[Starburst]

Everyone can read @djprmf, your reply (4th post) said:

They are not old. They have been publicly disclosed yesterday, but that doesn't mean that CWP servers are safe.
They have been fixed in recent CWP versions, but that doesn't mean that servers haven't been affected - even after they have been patched - by the exploit before the patch was even made.

NOT:

My original post stated: "They have been publicly disclosed yesterday." Because the article was published on November 5, my statement is a 100% accurate, undeniable fact.

Now you are leaving out what you said, when it started with:

They are not old.

FACT is the June date ALL the links even you posted reference.

Someone could write an article next week, and reference the June date, yet again.
Would not make it new publicly disclosed information...

[djprmf]

You are desperately clinging to the word "old", aren't you?

Let's look at your hypothetical scenario:

"Someone could write an article next week, and reference the June date, yet again. Would not make it new publicly disclosed information..."

You are 100% correct about that specific sentence! If someone writes about it next week, it won't be new.

But do you know when it WAS new publicly disclosed information? November 5, 2026.

Why? Because before November 5, 2026, I challenge you to find a single article, a single CVE, a single forum post, or a single security bulletin anywhere on the internet that mentions cwpdoor, cwpsrv_update.sh, or the hidden ngx_http_integrity_helper socket.

You won't find one.

The malware was deployed in June. XLab silently captured it in June. But the knowledge of its existence and how it works was kept strictly private until XLab published their findings on November 5.

Therefore, on November 6 (when I made my post), the public disclosure was literally 24 hours old. That is the definition of "not old." Threat intelligence is not "old news" to the community on the very first day the community is allowed to read it.

You can keep trying to win a semantic argument about the word "old", but it doesn't change the facts:
1. The public only learned how this backdoor works this week.
2. Updating CWP does not remove the backdoor if a server was already infected.

The facts, the actual publication dates, and the remediation steps are all documented in this thread for any SysAdmin who actually cares about securing their infrastructure. Have a good one.

[Starburst]

My reply still stands as being accurate, when adrianofnatal asked:

Hi all!

Did you all see this?

https://www.cisoadvisor.com.br/backdoor-cwpdoor-compromete-servidores-linux-via-cwp/
https://thehackernews.com/2026/11/hackers-hide-linux-backdoor-in-control.html

A backdoor in cwpsrv.

These are OLD, and have been fixed since 1.25.

The CVE's affected only 1.15.10 and 1.24.0 per the article.

I try to keep CVE announcements updated at:
https://sysadmin.help/viewforum.php?f=80

[djprmf]

My reply still stands as being accurate, when adrianofnatal asked:

Hi all!

Did you all see this?

https://www.cisoadvisor.com.br/backdoor-cwpdoor-compromete-servidores-linux-via-cwp/
https://thehackernews.com/2026/11/hackers-hide-linux-backdoor-in-control.html

A backdoor in cwpsrv.

These are OLD, and have been fixed since 1.25.

The CVE's affected only 1.15.10 and 1.24.0 per the article.

I try to keep CVE announcements updated at:
https://sysadmin.help/viewforum.php?f=80

Repeating your first post does not magically make it accurate. Since you want to stand by your original comment, let's break down exactly why it is factually incorrect and genuinely dangerous advice for any SysAdmin reading it:

1. "The CVE's affected only 1.15.10 and 1.24.0" False.
It is not a CVE. It is a custom-compiled post-exploitation backdoor (malware). Calling it a CVE demonstrates a fundamental misunderstanding of what this threat actually is.

2. "...and have been fixed since 1.25" Dangerously False.
An update to CWP prevents future exploitation, but it does absolutely nothing to remove the backdoor from a server that was already compromised. Telling administrators that an active root-level backdoor is "fixed" just because they ran a panel update gives a completely false sense of security.

3. "These are OLD" False.
The threat actors may have deployed it months ago, but the knowledge of how to detect it - the IoCs, the file paths, the hidden ngx_http_integrity_helper socket - was kept completely private by XLab until they published their research on November 5, 2026. Threat intelligence is not "old" on the exact week it is finally shared with the public to defend themselves.

You are stuck in a loop because your ego will not allow you to admit that your initial, knee-jerk reaction to the OP was flawed.

Anyone with basic server administration experience can read this thread, look at the actual November publication date on the XLab report, and understand why checking their servers for this specific malware is important today.

I have laid out the facts, the timelines, and the technical remediation steps. And even provide you with a challange to HELP YOU PROVE ME WRONG. I have nothing more to add to this loop. Have a great weekend.

[Starburst]

So according to your thought process, if someone writes an article about the CVE's from May/June in December 2026, then it would be "new publicly disclosed information"...

The one article you keep saying was updated on November 5th, 2026, begins saying with

On June 29, 2026 the XLab's Cyber Threat Insight and Analysis System(CTIA).

You might want to write them, and tell them their article has the wrong date, it's not June 29, 2026...

Here is an answer to your challange:

https://www.cisoadvisor.com.br/backdoor-cwpdoor-compromete-servidores-linux-via-cwp/

Published: 05/11/2026 @ 1743

Funny enough, this is a link that adrianofnatal posted in their original post...

Guess you didn't read that...

You are a funny troll...

[djprmf]

So according to your thought process, if someone writes an article about the CVE's from May/June in December 2026, then it would be "new publicly disclosed information"...

The one article you keep saying was updated on November 5th, 2026, begins saying with

On June 29, 2026 the XLab's Cyber Threat Insight and Analysis System(CTIA).

You might want to write them, and tell them their article has the wrong date, it's not June 29, 2026...

Here is an answer to your challange:

https://www.cisoadvisor.com.br/backdoor-cwpdoor-compromete-servidores-linux-via-cwp/

Published: 05/11/2026 @ 1743

Funny enough, this is a link that adrianofnatal posted in their original post...

Guess you didn't read that...

You are a funny troll...

This is the part where you might want to take a deep breath and look closely at the URL you just posted.

You linked to cisoadvisor.com.br. That is a Brazilian website.
In Brazil, just like in Europe and most of the world, dates are formatted as DD/MM/YYYY.

When that website says "Published: 05/11/2026", that translates to November 5, 2026. It does not mean May 11.

You literally just posted November 5th as your definitive proof that the article wasn't published on November 5th.
Thank you for accidentally validating my exact argument while trying to call me a troll.

To quickly address your other points before we wrap this up:

1. The December hypothetical
If someone writes about this in December, it won't be "newly disclosed." Why? Because the first public disclosure already happened on November 5. The first time a private discovery is shared with the world is the disclosure date. Everything after that is just reporting.

2. The XLab June 29 date
I never once said XLab had the wrong date. I said - for the fifth time - that June 29 is the day their internal systems captured the malware. They did not publish the report to the public on that day. They published it on November 5.

Your grand finale was misreading a basic international date format to defend a flawed technical argument about server incident response. I think this thread has provided more than enough facts for any SysAdmin reading it to draw their own conclusions.

[Starburst]

Dear lord, do you actually read the link, even you posted...

They ALL state:

1.15.10 and 1.24.0

https://thehackernews.com/2026/11/hackers-hide-linux-backdoor-in-control.html

3rd line of the 3rd paragraph. Depending on screen setup.

So stop with your mis-information troll.

I can keep busting your false information, but apparently you don't have a life or a job like the rest of us do...

[djprmf]

Dear lord, do you actually read the link, even you posted...

They ALL state:

1.15.10 and 1.24.0

https://thehackernews.com/2026/11/hackers-hide-linux-backdoor-in-control.html

3rd line of the 3rd paragraph. Depending on screen setup.

So stop with your mis-information troll.

I can keep busting your false information, but apparently you don't have a life or a job like the rest of us do...

I see we are completely ignoring your hilarious date format blunder and frantically pivoting back to version numbers.


For the record, I never denied the malicious installer targeted versions 1.15.10 and 1.24.0. In fact, I explicitly agreed with that and explained why in my earlier replies: the attackers custom-compiled their backdoor to match those exact releases so they wouldn't crash the web server.

But here is the critical incident response concept you are still failing to grasp:
1. A server is running 1.24.0 in July.
2. The attacker runs the installer and infects the server.
3. The SysAdmin updates CWP to 1.25.0 (or 1.30) later on.
4. The backdoor is still there.

The fact that the initial installer only targeted those two versions does not mean servers running newer versions today are magically clean. A panel update does not perform forensic malware removal. That is why the newly published threat intelligence and IoCs are critical for administrators to check their systems right now.

Since you have completely run out of technical arguments, quietly ignored your own misreading of the publication dates, and have now resorted to personal insults, this conversation has hit rock bottom.

I actually do have a job managing real infrastructure, which requires understanding how post-exploitation persistence works rather than just reading version numbers.