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.
Same CVEs as mentioned here?
https://sysadmin.help/viewforum.php?f=80
Quote from: adrianofnatal on November 06, 2026, 09:16:42 PMHi 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
Quote from: Starburst on November 07, 2026, 01:11:26 AMQuote from: adrianofnatal on November 06, 2026, 09:16:42 PMHi 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.
Quote from: djprmf on November 07, 2026, 07:45:52 AMThey 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:
Quotehttps://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:
Quotehttps://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...
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.
Quote from: djprmf on November 07, 2026, 04:47:57 PMYou 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:
Quotehttps://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:
Quotehttps://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:
QuoteThey 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.
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.
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:
QuoteOn June 29, 2026, the XLab's Cyber Threat Insight and Analysis System(CTIA)
QuoteOn September 30, 2026, a file named evidencia.tgz was uploaded to VirusTotal from Brazil.
Quotebasic 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.
QuoteThey 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.
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.
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...
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.
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
Quotehttps://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.
Quotehttps://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.
Quotehttps://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:
QuoteThey 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...
Whoever wrote the first article back in June, should sue all these other sites for plagiarism.
They even use the same graphics.
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.
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.
Quote from: Starburst on November 07, 2026, 09:01:09 PMOnly Fact is this information is from JUNE, which even the articles state. NOT November.
(https://cdn.tugatech.com.pt/imagens/artigos/2026/11/07/tugatech-9840-66927.jpg)
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
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.
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
You are funny @djprmf
Now Read UNDER the graphic below the that title, and it says:
QuoteOn 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
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.
Everyone can read @djprmf, your reply (4th post) said:
QuoteThey 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:
QuoteMy 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:
QuoteThey 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...
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.
My reply still stands as being accurate, when adrianofnatal asked:
QuoteHi 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.
QuoteThese 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
Quote from: Starburst on November 07, 2026, 09:31:53 PMMy reply still stands as being accurate, when adrianofnatal asked:
QuoteHi 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.
QuoteThese 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.
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
QuoteOn 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:
Quotehttps://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...
Quote from: Starburst on November 07, 2026, 09:41:30 PMSo 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 QuoteOn 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:
Quotehttps://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 hypotheticalIf 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 dateI 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.
Dear lord, do you actually read the link, even you posted...
They ALL state:
Quote1.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...
Quote from: Starburst on November 07, 2026, 09:45:28 PMDear lord, do you actually read the link, even you posted...
They ALL state:
Quote1.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 (https://forum.centos-webpanel.com/informations/cwpsrv-backdoor-announced-in-some-security-websites/msg54865/#msg54865) 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.
Lookup CVE-2026-42945 from May 2026. It's aka NGINX Rift
That RCE went out in the middle of May.
Thru that and really any RCE, even the one PHP had a few weeks ago, could allow a hacker to deploy the CWPdoor payload or other SSH backdoors.
So even if you fixed whatever caused the original RCE, CWPdoor would still be there.
Quote from: Starburst on November 07, 2026, 10:05:26 PMLookup CVE-2026-42945 from May 2026. It's aka NGINX Rift
That RCE went out in the middle of May.
Thru that and really any RCE, even the one PHP had a few weeks ago, could allow a hacker to deploy the CWPdoor payload or other SSH backdoors.
So even if you fixed whatever caused the original RCE, CWPdoor would still be there.
"So even if you fixed whatever caused the original RCE, CWPdoor would still be there."Exactly! Welcome to the exact point I made in my very first reply to this thread.You have just perfectly explained why I said a panel update doesn't automatically clean a compromised system. Patching the initial entry vector (whether it is an Nginx RCE, a PHP bug, or anything else) stops new attacks, but it does absolutely nothing to remove the post-exploitation backdoor that is already running in the background.
This is exactly why your initial claim - telling everyone "these are OLD, and have been fixed since 1.25" - was so dangerous. Updating to 1.25 fixes the software, but it leaves the CWPdoor backdoor completely untouched.
That is precisely why the publication of these specific IoCs (Indicators of Compromise) by XLab this week is so important. SysAdmins need this new threat intelligence to hunt down the exact backdoors that regular updates leave behind.
As for your mention of CVE-2026-42945 - please don't try to muddy the waters with completely unrelated vulnerabilities. That specific Nginx CVE has absolutely nothing to do with the targeted CWPdoor malware campaign detailed in the XLab report.
Ok boys n girls i have a spare room if you wanna get it on.
This is like watching an episode of love island.