CWPSRV backdoor announced in some security websites

[adrianofnatal]

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.

[overseer]

Same CVEs as mentioned here?
https://sysadmin.help/viewforum.php?f=80

[Starburst]

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]

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

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.

[Starburst]

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.

Then what are the CVE numbers?

I get automatic notifications directly from CISA and also the cvefeed.io

None have come across my desk as of 2026-11-07 1613Z, other than the ones I put online.

The one article quotes above, shows your statement as false, as it is dated 2026-05-11, and specifically states:

https://www.cisoadvisor.com.br/backdoor-cwpdoor-compromete-servidores-linux-via-cwp/
Researchers discovered the malware on June 29 after capturing a script disguised as an updater that replaced the legitimate 'cwpsrv' binary with a malicious version. The script replaces versions 1.15.10 and 1.24.0 of cwpsrv and takes several measures to hide the change, such as restoring file and directory timestamps, deleting temporary files, and clearing the command history log.

The other article states the same info:

https://thehackernews.com/2026/11/hackers-hide-linux-backdoor-in-control.html
The researchers, who named the backdoor cwpdoor, captured its installer, a shell script posing as a version update, on June 29. The installer handles only two versions of that web server, cwpsrv 1.15.10 and 1.24.0. The researchers do not yet know how attackers get the root access the installer needs.

FYI, we are in November, not June.
Also take note, it only specifies 2 versions, not a range.

AND currently at 1.30.4, NOT 1.15.0 or 1.24.0, which where the ONLY 2 affected versions:
1.24.0 came out, and was fixed with 1.25.0 (Same day - 2026-10-25)
1.15.0 came out 2026-09-28 and was fixed with 1.16.0 the next day on 2026-09-29.

Given your past posting history of hate and false information about CWP doesn't help your case, and yet here you are, posting more false information, yet again...

[djprmf]

You are fundamentally conflating two different concepts: a software vulnerability (CVE) and a trojanized post-exploitation backdoor (Malware).


CVEs are assigned to software bugs and vulnerabilities in source code. CWPdoor is not a vulnerability; it is a backdoor. Malware families (such as Ebury, Mirai, or CWPdoor) do not receive CVE IDs. Threat actors obtained root access (vector still under investigation) and deployed a custom installer (cwpsrv_update.sh) that replaced the legitimate cwpsrv binary with a backdoored version. CISA / cvefeed will not notify you of malware families unless a specific upstream vulnerability ID is published.


About the timeline and disclosure date:
The research by 360 XLab was publicly disclosed on November 5, 2026. In cybersecurity research, capturing an installer sample in June, observing fresh samples on VirusTotal in late September, and releasing a coordinated report in November is standard industry timeline. The disclosure is fresh, even if the campaign was running prior to detection.

About the versions, again, many wrong sentences...
The installer specifically targeted cwpsrv 1.15.10 and 1.24.0 because the attackers custom-compiled replacement binaries matching those exact versions so the web server wouldn't crash or trigger obvious version mismatches.


A regular CWP upgrade to 1.30.4 does not automatically remediate an already compromised server. If a machine was compromised while on an earlier version:

• The backdoor alters /usr/local/cwpsrv/bin/cwpsrv, restores file timestamps (touch/stat spoofing) to hide itself, and communicates via a hidden Unix domain socket (ngx_http_integrity_helper) without writing to access logs.   
• Simply upgrading a package does not clean persistence mechanisms, audit rogue SSH keys, or rotate compromised root and database credentials. Once root is compromised, standard incident response applies.

Instead of dismissing the report, administrators should verify their systems against the published Indicators of Compromise (IoCs)

Being proactive about server security helps everyone in the community. Checking servers for these IoCs takes thirty seconds and ensures systems are actually clean.

[Starburst]

You are fundamentally conflating two different concepts: a software vulnerability (CVE) and a trojanized post-exploitation backdoor (Malware).


CVEs are assigned to software bugs and vulnerabilities in source code. CWPdoor is not a vulnerability; it is a backdoor. Malware families (such as Ebury, Mirai, or CWPdoor) do not receive CVE IDs. Threat actors obtained root access (vector still under investigation) and deployed a custom installer (cwpsrv_update.sh) that replaced the legitimate cwpsrv binary with a backdoored version. CISA / cvefeed will not notify you of malware families unless a specific upstream vulnerability ID is published.


About the timeline and disclosure date:
The research by 360 XLab was publicly disclosed on November 5, 2026. In cybersecurity research, capturing an installer sample in June, observing fresh samples on VirusTotal in late September, and releasing a coordinated report in November is standard industry timeline. The disclosure is fresh, even if the campaign was running prior to detection.

About the versions, again, many wrong sentences...
The installer specifically targeted cwpsrv 1.15.10 and 1.24.0 because the attackers custom-compiled replacement binaries matching those exact versions so the web server wouldn't crash or trigger obvious version mismatches.


A regular CWP upgrade to 1.30.4 does not automatically remediate an already compromised server. If a machine was compromised while on an earlier version:

• The backdoor alters /usr/local/cwpsrv/bin/cwpsrv, restores file timestamps (touch/stat spoofing) to hide itself, and communicates via a hidden Unix domain socket (ngx_http_integrity_helper) without writing to access logs. 
• Simply upgrading a package does not clean persistence mechanisms, audit rogue SSH keys, or rotate compromised root and database credentials. Once root is compromised, standard incident response applies.

Instead of dismissing the report, administrators should verify their systems against the published Indicators of Compromise (IoCs)

Being proactive about server security helps everyone in the community. Checking servers for these IoCs takes thirty seconds and ensures systems are actually clean.

I quoted the articles with links EXACTLY was you stated in your post.

Hell, that are viruses that are years old still floating around. Doesn't mean any systems are still vulnerable.

That 360 XLab states the same:

https://brandefense.io/security-news/control-web-panel-linux-backdoor/
XLab found the backdoor rebuilt into cwpsrv versions 1.15.10 and 1.24.0. CWP's own current releases, 1.30 and 1.30.1, are newer, though that alone does not remove a backdoor an attacker with root could still plant.

The original Xlab article was dated 2026-11-05, but is just an update of the article from 2026-06-29, as the article even shows:

https://blog.xlab.qianxin.com/cwpdoor-the-invisible-backdoor-living-inside-control-web-panel/

Background
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.

It only affected versions 1.15.0 and 1.24.0, which where promptly fixed.

I love how all these articles say the same thing, even the same type-o of 1.15.10 (which never existed)

And yes, if you where 'hacked' on one of those days, updating CWP doesn't automatically clean a system, that is the SysAdmin's job to do.
That is nothing new.

I still standard as you stated:

They are not old. They have been publicly disclosed yesterday, but that doesn't mean that CWP servers are safe.

So what CVE's where publicly disclosed on 2026-11-06?

And nothing is 'safe' anymore, especially with AI.

That's why companies run honeypots, and look at logs and warnings from their systems.

[djprmf]

I am glad we are now on the same page that updating CWP does not magically clean a compromised server. This actually contradicts your initial claim that these issues "have been fixed since 1.25". A panel update is not an incident response plan, which is exactly why discussing this recent disclosure is important.

To address your points directly:

1. "So what CVE's where publicly disclosed on 2026-11-06?"
The answer is zero. I must stress this again: CWPdoor is a post-exploitation malware family, not a software vulnerability. CVEs (Common Vulnerabilities and Exposures) are assigned to flaws in source code (like a buffer overflow or an RCE). Malware payloads and botnets do not receive CVE IDs. Asking for a CVE for CWPdoor is like asking for a CVE for the Mirai botnet.

2. The June vs. November timeline
You are misreading the XLab report. June 29 is not an older article date; it is the date XLab's threat intelligence system captured the initial malicious script. In cybersecurity, it is standard industry practice to capture a sample, monitor its Command & Control (C2) infrastructure, reverse-engineer the payload, and wait several months before publishing a comprehensive whitepaper. The report itself was published this week.

3. The 1.15.10
The version 1.15.10 is not a typo repeated by journalists. It is the specific version string hardcoded into the attackers' own shell script (cwpsrv_update.sh). The threat actors custom-compiled their backdoor to match the exact Nginx core versions they were finding on their target servers at the time, to avoid crashing the web server and raising suspicion.

4. Why this matters now
You stated: "if you where 'hacked' on one of those days, updating CWP doesn't automatically clean a system, that is the SysAdmin's job to do."

Exactly. And how is a SysAdmin supposed to do their job and hunt for this specific threat if the Indicators of Compromise (IoCs) - like the hidden Unix domain socket ngx_http_integrity_helper - were only made public by researchers this week?

That is the entire point of sharing the news. It is not about CWP being currently vulnerable to a new CVE. It is about warning administrators to check their systems against newly published IoCs to ensure they weren't silently compromised months ago.

[Starburst]

I NEVER claimed that the new CWP version magically 'cleaned' a server...

The XLab report you keep referencing does have an UPDATE/Correction date of 2026-11-05, but the article clearly starts with:

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

On September 30, 2026, a file named evidencia.tgz was uploaded to VirusTotal from Brazil.

basic information about the infection script captured on June 29, 2026, is shown below:

So it has nothing to do with this November date of an exploit/vulnerability.

And 1.5.10 never existed as a CWP version, only 1.15.0 and 1.16.0 where, hence they keep repeating something that never existed.

Their have been plenty of CVE's about Nginx, and doesn't single out CWP.
The XLab article does have ways to check your server, if you where/are running Nginx, which is nice.

It would have affected ANYONE running Nginx, period.

BTW There are CVE's about CWPdoor.

A botnet is NOT an system exploit/vulnerability.

It IS a group of systems that where hacked thru an system exploit/vulnerability or fraudulently purchased systems to attack other systems.

[Starburst]

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.

So what CVE/exploit/vulnerability was published yesterday (2026-11-06)?

Still waiting for you to substantiate your claim in your original post above with a link as evidence...

So far, you have posted ZERO link(s) as your evidence of a 'new' CVE/exploit/vulnerability from 2026-11-06, where I have, that shows the date back in June.

If a new one was posted yesterday (2026-11-07) as you claim, I would like a link so I can review it.

[djprmf]

You are demanding evidence for a claim I never made. Please read my quote again. I never used the words "new CVE" or "new vulnerability". I explicitly stated that the malware and its details were publicly disclosed yesterday.

You are asking for links showing a November disclosure? The very links in the original post of this thread are the evidence:

- XLab published their original threat intelligence report on November 5, 2026.
- The Hacker News and CISO Advisor published their articles reporting on XLab's findings on November 5/6, 2026.

As I explained previously, June 29 is simply the date XLab's internal systems captured the payload in the wild. It is not the date they told the public about it. The public disclosure - which includes sharing the hidden socket names, the exact file paths, and the mechanism with the community so we can defend ourselves - happened this week. That is exactly what "publicly disclosed" means.

Furthermore, demanding a "CVE/exploit" link to validate a malware campaign shows a fundamental misunderstanding of threat intelligence. Malware families do not receive CVE numbers.
And i repeat so you understand: MALWARE families DO NOT receive CVEs!

If a SysAdmin only secures their servers based on CVE announcements and ignores newly published malware Indicators of Compromise (IoCs) just because "it's not a CVE", they are leaving their infrastructure completely blind to post-exploitation threats.

The evidence of the disclosure is the XLab report from this week. The actionable takeaway for sysadmins is to check their servers for the ngx_http_integrity_helper socket. If you choose to ignore newly published threat intelligence because YOU are hyper-fixated on finding a CVE number, that is your choice as a server administrator. Its wrong, but the servers are yours. Just don't propagate that info to other sysadmins, because is factualy wrong.

[Starburst]

Still waiting for you to substantiate your claim in your original post above with a link as evidence...

But I know you can't, because what you are posting is false...

Prove me wrong, post the link(s)...

Post them or shut the frak up with your mis-information...

[djprmf]

The links you are asking for are literally in Post #1 of this exact thread. The original poster shared them. You even quoted them yourself in your very first reply.
 
Here they are again, in case scrolling to the top of the page is the issue:
The Hacker News: https://thehackernews.com/2026/11/hackers-hide-linux-backdoor-in-control.html (Published Nov 5, 2026)
 
CISO Advisor: https://www.cisoadvisor.com.br/backdoor-cwpdoor-compromete-servidores-linux-via-cwp/ (Published Nov 6, 2026)
 
XLab Primary Research: https://blog.xlab.qianxin.com/cwpdoor-the-invisible-backdoor-living-inside-control-web-panel/ (Published Nov 5, 2026)
 
These reports, published yesterday and today, constitute the "public disclosure" I mentioned in my original post. They are the articles that detail the post-exploitation malware, the hidden sockets, and the payload.
 
If you choose to ignore actionable threat intelligence just because it doesn't have a CVE number, and prefer throwing insults instead of reading the links at the top of the thread, that is your choice.

[Starburst]

You might want to READ, the links you posted, even they show they are from an issue in June, and are NOT relevant anymore, as they where fixed in CWP 1.16.0 and 1.25.0

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

The researchers, who named the backdoor cwpdoor, captured its installer, a shell script posing as a version update, on June 29. The installer handles only two versions of that web server, cwpsrv 1.15.10 and 1.24.0. The researchers do not yet know how attackers get the root access the installer needs.

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

Researchers discovered the malware on June 29 after capturing a script disguised as an updater that replaced the legitimate 'cwpsrv' binary with a malicious version. The script replaces versions 1.15.10 and 1.24.0 of cwpsrv and takes several measures to hide the change, such as restoring file and directory timestamps, deleting temporary files, and clearing the command history log.

https://blog.xlab.qianxin.com/cwpdoor-the-invisible-backdoor-living-inside-control-web-panel/


Background
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.

Those sites might have just published something yesterday.

But even they ALL state it's from back in June 2026...

So your statement of:

They are not old. They have been publicly disclosed yesterday, but that doesn't mean that CWP servers are safe.

Is still false, as nothing new had been publicly disclosed that hadn't been back in June's CVE's...

[Starburst]

Whoever wrote the first article back in June, should sue all these other sites for plagiarism.

They even use the same graphics.