Control Web Panel Backdoor Hides in cwpsrv: How to Check

QiAnXin's XLab lab disclosed on November 5, 2026 a backdoor it calls "cwpdoor", hidden inside cwpsrv, the web server that runs Control Web Panel (CWP). It targets Linux servers with CWP where an attacker already has root. It leaves no trace in access logs, but three commands can reveal it.

What we know

What it is: according to XLab, a copy of cwpsrv with extra code. It behaves like the normal program until it gets a request with special signed headers, then runs the attacker's commands. Those requests do not show up in access logs.
Versions: XLab captured two samples, for cwpsrv 1.15.10 and 1.24.0; the installer supports only those two.
How it gets there: the installer, a script posing as a cwpsrv update, must run as root. XLab says it does not yet know which vulnerability attackers use to get that far.
How it hides: per XLab, the installer restores the file's original timestamps, so `ls` and `stat` show nothing unusual.
Timeline: XLab captured the installer on June 29, 2026. On September 30, someone in Brazil uploaded an archive with a copy of the backdoor to VirusTotal, where no engine flagged it; XLab reads that as evidence of real victims.
Scale: XLab gives no count of infected servers. It cites, from its Hunter platform, more than 340,000 internet-facing CWP instances in the past month as potential targets, not confirmed victims.
Also in the sample: the Brazil archive also held a component most antivirus engines identify as Ebury, which The Hacker News describes as an OpenSSH backdoor and credential stealer. XLab does not know whether the two are related.
Vendor: the report includes no statement from the CWP developers.

What changes and what doesn't

Changes for anyone running CWP on a VPS: there is now a concrete, published way to tell whether the panel's web server was tampered with.
It is not a new CWP bug that a patch fixes. It is what an attacker leaves behind after getting root. The real question is how they got in.
Does not affect, based on what was published, servers without Control Web Panel: the script only replaces CWP's cwpsrv. cPanel or Plesk servers do not have that file.

How to check your server

If you run a VPS with Control Web Panel, log in over SSH as root and run XLab's three checks:

`ss -axp | grep integrity` — if `ngx_http_integrity_helper` shows up, the server is infected. According to The Hacker News, in one case this was the only sign; the open-ports list looked normal.
`ps aux | grep cwpsrv` — look for unexpected helper processes started by cwpsrv.
`strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity` — any output means the binary carries the backdoor's headers.

Also run `md5sum /usr/local/cwpsrv/bin/cwpsrv` and compare it with XLab's two hashes: `965aea67fb40de1bab5169ada993349f` (1.15.10) and `d3f4e95113d49ab3991b45e457bda75b` (1.24.0). A match means infection. No match only rules out those two samples.

If any check is positive, XLab recommends:

Restore the original cwpsrv from the `cwpsrv.prev-<date>` backup in `/usr/local/cwpsrv/bin` (the installer may have deleted it).
Upgrade CWP to the latest version and re-run `ss -axp | grep integrity` until it returns nothing.
Change every panel credential and treat the whole server as compromised: whoever installed this already had root.

In practice, a server where someone had root is not clean just because one file was replaced. The safer path is to copy the site and database, check them for injected code, and move them to a fresh server.

If all checks come back clean: good, but that does not prove nobody got in. Also review new users, keys in `authorized_keys`, and connections to the download server address XLab published (136.0.141[.]71).

If someone else manages your hosting: ask your provider: "Do my servers run Control Web Panel? Have you checked cwpsrv against XLab's November 5 report?"

Sources

Updates: if the CWP developers respond or the entry point becomes known, it will be added here with a link.