CWPdoor: backdoored cwpsrv hides in Control Web Panel servers, how to check with ss -axp

Researchers at XLab, the threat-research arm of QiAnXin, published an analysis on 5 November 2026 of CWPdoor, a Linux backdoor that is delivered by replacing cwpsrv, the web server behind the free Control Web Panel (CWP, formerly CentOS Web Panel) hosting interface. It only wakes up for a correctly signed request, keeps that request out of the access logs, and had zero detections on VirusTotal when a sample surfaced there. XLab says real victims exist but does not know how the implant gets onto servers. If you run CWP, the useful part is below: three quick checks you can run today and what to do if one hits.

Key points

• CWPdoor is a passive backdoor built into a recompiled cwpsrv; it runs attacker commands only when a request carries three X-Ngx-Integrity-* headers with a valid timestamp and RSA signature (XLab).
• XLab captured the infection script cwpsrv_update.sh on 29 June 2026; it supports only cwpsrv versions 1.15.10 and 1.24.0 and must run as root.
• A sample uploaded to VirusTotal from Brazil on 30 September 2026 had zero detections; XLab concludes real victims already exist.
• XLab does not know how the backdoor spreads or which vulnerability, if any, it uses.
• XLab counts more than 340,000 CWP instances exposed to the internet over the past month; that is exposure, not a count of infections.

What to do

Who is affected. Servers running Control Web Panel on Linux. The infection script XLab captured handles cwpsrv 1.15.10 and 1.24.0 only. That describes what the script replaces; it does not mean every install of those versions is infected. XLab's two samples target those two versions.

Check whether you are affected (run as root on the CWP host; these are XLab's triage checks):

1. ss -axp | grep integrity : a match on a Unix socket named ngx_http_integrity_helper is the main sign.
2. ps aux | grep cwpsrv : look for suspicious helper child processes attached to cwpsrv.
3. strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity : any hit means the backdoor's header names are in the binary.

A clean result is reassuring but not proof. The malware is built to hide, and the infection script restores the binary's access and modification times, so ls and stat will show a file that looks untouched. XLab also publishes indicators: the script's MD5 e505d4ffa21cf494a5dc2d7c8f4f1236, the 1.15.10 sample 965aea67fb40de1bab5169ada993349f, the 1.24.0 sample d3f4e95113d49ab3991b45e457bda75b, and the download server 136.0.141.71 (search your network or proxy logs for connections to it). The attackers recompile the server, so other builds may have different hashes.

If you find a hit, XLab recommends:

1. Look in /usr/local/cwpsrv/bin for the backup the script makes, named like cwpsrv.prev-YYYYMMDD-HHMMSS, and use it to replace the malicious cwpsrv after verifying it yourself.
2. Upgrade to the latest CWP version and confirm ss -axp | grep integrity no longer matches.
3. Rotate all control-panel credentials at once. The backdoor runs arbitrary commands, so XLab says to treat those credentials as compromised, to treat the whole host as compromised, and to look for other malware on it.

What happened

On 29 June 2026 XLab's threat-analysis system captured a script called cwpsrv_update.sh. It downloads a file named cwpsrv from 136.0.141.71 and swaps it in for the real one. The researchers found the downloaded file is not a separate program: the attacker inserted malicious code into the cwpsrv source and recompiled it, so a server that looks and behaves like CWP's own hides the backdoor inside it. XLab named it CWPdoor after its target.

The script is dressed as a version update. It checks the local cwpsrv version, downloads the matching binary, backs up the original, stops the service, overwrites /usr/local/cwpsrv/bin/cwpsrv, restarts it and confirms that the master, worker and helper processes are running. If that health check fails it rolls back. If it succeeds, it deletes the temporary files and the backup, restores the file and parent-directory timestamps, and runs history -d to remove the command from the session history. It reports the result to the same address it downloaded from.

On 30 September 2026 an archive named evidencia.tgz was uploaded to VirusTotal from Brazil. It held two files: libkeyutils.so.1.5.2, which most vendors correctly flagged as the Ebury backdoor, and cwpsrv.suspeito, which is CWPdoor and had zero detections. XLab concludes the campaign was not merely experimental. BleepingComputer, which reported the findings the same day, repeats that conclusion. XLab adds that the link between Ebury and CWPdoor is unclear and that the two families may have been planted on the same server by different attackers.

How it works

CWP's cwpsrv is a customised Nginx-based server that serves the panel interface. CWPdoor adds two functions. One runs at start-up, finds the logging module, creates the Unix socket ngx_http_integrity_helper and starts a helper child process. The other runs at the entry point of request handling and looks for three headers:

Header	Purpose
X-Ngx-Integrity-Time	Timestamp
X-Ngx-Integrity-Data	Base64 of the AES-encrypted command
X-Ngx-Integrity-Sig	Base64 RSA signature

The backdoor accepts a request only if the timestamp falls within 300 seconds either side and the signature verifies against an RSA public key embedded in the binary (stored XOR-masked and recovered by XORing each byte with 0x55). The signed value is the timestamp and the data joined together, so changing either invalidates the signature; XLab says this gives the operators replay protection. The command is the Base64 text decoded: the first 16 bytes are the AES initialisation vector, the rest AES-256-CBC ciphertext, with the key derived from a SHA-256 digest of the embedded public-key string. The master process passes the decrypted command to the helper over the Unix socket, and the encrypted result comes back as an HTTP 200 with content type application/octet-stream.

If any check fails, the request is handled as ordinary traffic and nothing visible happens. In effect, a scanner cannot trigger the backdoor without the attackers' private key. When a request does trigger it, the code tampers with that request's module context so the logging module is skipped. The consequence for defenders, as XLab frames it: a clean access log proves nothing, and hunting for odd requests there will miss this activity.

Background

CWP is a free, open-source alternative to cPanel and Plesk, used to manage websites, DNS, email and databases without the command line. It has been a repeated target. In 2021 The Record reported that a threat actor had been scanning for CWP installs since February that year and using an exploit for an old vulnerability to install a backdoor called Facefish, with more than 185,000 CWP installations visible online at the time. A Center for Internet Security advisory (numbered 2025-100) later warned of a CWP flaw that could let an attacker bypass authentication and trigger command injection. Nothing in XLab's report ties CWPdoor to either of those, and we do not claim a link.

The exposure count has grown since: XLab, using QiAnXin's Hunter search platform, counts more than 340,000 CWP instances reachable from the internet over the past month, against the 185,000 The Record cited in 2021. The two figures come from different search engines in different years, so they are not a like-for-like trend.

CWP's own changelog shows an active release stream: version 1.30.1, released 3 November 2026, is described as a security and stability update of the LTS version, and says CWP update checks and updates are now downloaded only over verified HTTPS. The changelog does not mention CWPdoor, and we do not know whether the update affects this campaign. XLab tells affected admins to upgrade to "the latest version" without naming one.

What it means

For hosting providers and anyone running CWP on public ports, the lesson is that the file-integrity story matters more than the log story here. Because the script resets timestamps and the backdoor suppresses logging, the usual forensic shortcuts fail. Compare the binary against a known-good copy from the vendor, check for the socket and strings, and treat network egress to the download address as a red flag.

For defenders generally, a zero-detection sample that sat on VirusTotal is a reminder that signature-based tools lag a compile-it-yourself implant. The cheapest durable defences are the old ones: keep management panels off the open internet where possible, restrict them by IP, and monitor for changes to the web server binary.

What we don't know yet

• How servers get infected. XLab says it does not know the spread mechanism or any vulnerability involved. The script needs root, but the research does not show how attackers get it.
• How many servers. XLab gives no victim count and names no victims. The 340,000 figure is exposure only.
• The Ebury link. XLab cannot say whether Ebury and CWPdoor on the same server are related.
• Who is behind it. No attribution has been published.
• Other versions. Only 1.15.10 and 1.24.0 builds have been seen; the attackers could build for others.

What to watch next

Watch XLab's follow-up, since it has asked peers with wider visibility for leads on distribution. Watch the CWP project for a statement on the campaign and for any fix to how updates are fetched. Watch VirusTotal and endpoint vendors for detections of the XLab hashes, and see our earlier reports on other backdoored update channels, such as cPGuard's hijacked updates.

Sources

• XLab: CWPdoor, the invisible backdoor living inside Control Web Panel
• BleepingComputer: Hackers backdoor Linux servers using trojanized CWP web server
• Windows Forum: CWPdoor Linux backdoor hides in Control Web Panel, detection and response guide
• The Record: Malware campaign targets server hosting software CWP (2021)
• Center for Internet Security: A vulnerability in CWP could allow for remote code execution
• Control Web Panel changelog