A newly documented Linux backdoor can give attackers remote command execution through Control Web Panel (CWP) without leaving the usual traces in access logs. Named CWPdoor, the malware is built directly into a modified version of cwpsrv, the web server that runs CWP's management interface.
Researchers at QiAnXin XLab disclosed the threat on Nov. 5 after analyzing an installer captured in June and malicious binaries targeting two cwpsrv versions. The installer requires root privileges, suggesting attackers already have substantial control of a server before deploying the backdoor.
XLab identified more than 340,000 internet-exposed CWP instances through its Hunter platform. That figure describes potential targets, not confirmed infections. An archive uploaded to VirusTotal from Brazil in September contained a CWPdoor sample, providing evidence that the malware has appeared outside a testing environment.
For administrators, the immediate priority is checking the running server and its binaries rather than relying solely on antivirus results, file timestamps, or clean access logs.
How CWPdoor compromises Control Web Panel servers
CWPdoor isn't a separate malware program running alongside CWP. Attackers modify the source code of cwpsrv, compile a malicious version, and replace the legitimate server binary.
The installer, cwpsrv_update.sh, poses as a routine update. It checks the installed version, downloads a matching malicious binary from 136.0.141.71, and replaces /usr/local/cwpsrv/bin/cwpsrv.
The captured installer supports versions 1.15.10 and 1.24.0. XLab has not established whether other versions have been targeted, and it has not identified the vulnerability or intrusion method attackers use to gain initial access.
Because the installer requires root privileges, CWPdoor is a post-compromise tool rather than a confirmed initial infection method. Similar post-compromise backdoors can give attackers persistent access after they have already breached a system.
Once installed, the modified server continues handling ordinary requests. The backdoor activates only when an attacker sends a request containing three specially crafted headers:
X-Ngx-Integrity-TimeX-Ngx-Integrity-DataX-Ngx-Integrity-Sig
The server validates the request's timestamp within a plus-or-minus 300-second window and checks an RSA signature. It then decrypts the command, sends it to a helper process through a Unix domain socket, and returns encrypted output to the attacker.
CWPdoor also suppresses logging for the triggering request. The installer restores the original file and directory timestamps and attempts to delete its command from shell history. These measures can make a compromised installation appear unchanged during routine checks.
Such stealth and persistence techniques have also appeared in Linux malware targeting cloud environments, where attackers try to maintain access without triggering conventional security alerts.
XLab reported that its analyzed CWPdoor sample initially received zero detections from 63 antivirus engines on VirusTotal. That result applies to the sample and scan at the time of testing, not necessarily to current security products.
How to detect CWPdoor on a Linux server
XLab recommends checking for the Unix domain socket used by the backdoor's command-execution helper.
Run:
ss -axp | grep integrity
A result containing ngx_http_integrity_helper is a strong indicator that the backdoor may be active.
Administrators can also inspect the installed binary for CWPdoor's custom request headers:
strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity
Check the running CWP processes for unexpected helper processes:
ps aux | grep cwpsrv
These checks are most useful together. An absence of matches does not conclusively establish that a server is clean, particularly if an attacker has modified or removed artifacts.
Published CWPdoor indicators of compromise
XLab published the following MD5 hashes:
- Installer script:
e505d4ffa21cf494a5dc2d7c8f4f1236 - Backdoored cwpsrv 1.15.10:
965aea67fb40de1bab5169ada993349f - Backdoored cwpsrv 1.24.0:
d3f4e95113d49ab3991b45e457bda75b
The identified download server is 136.0.141.71, with paths including /static/cwpsrv_update.sh and binaries corresponding to the two targeted versions.
Administrators should search available network telemetry, file inventories, and security records for these indicators. Because the installer requires root privileges, the investigation should extend beyond the CWP process to other evidence of unauthorized access.
XLab also found an Ebury-associated file, libkeyutils.so.1.5.2, alongside CWPdoor in the archive uploaded from Brazil. Researchers have not established whether the two malware families were deployed by the same attackers.
How to remove CWPdoor and recover a compromised server
XLab recommends restoring a legitimate cwpsrv binary, upgrading CWP, checking that the suspicious socket is gone, rotating control panel credentials, and investigating the host for additional threats.
The original binary may not be available locally. Although the installer creates a backup named cwpsrv.prev- followed by a timestamp, it deletes that backup after a successful installation. Any remaining backup from a compromised host should be treated cautiously.
Because CWPdoor's installer requires root privileges, replacing the binary alone cannot establish that the rest of the server is trustworthy.
The same recovery concern arises when other server backdoors survive software updates. In one recent Adobe Commerce incident, administrators were advised to investigate persistence and rotate exposed credentials rather than assume a patch had removed every threat.
For a confirmed CWPdoor compromise, administrators should:
- Isolate the affected host to prevent further unauthorized access while preserving evidence needed for investigation.
- Investigate the intrusion, including privileged logins, suspicious processes, unexpected files, and outbound connections.
- Rebuild from a trusted installation when the integrity of the operating system cannot be established. Avoid carrying potentially compromised system binaries into the replacement environment.
- Rotate exposed credentials, including CWP administrator passwords, SSH credentials, database passwords, hosting accounts, and application secrets.
- Verify recovery by checking the installed binaries, running processes, network connections, and the absence of CWPdoor's known indicators.
XLab advises upgrading CWP to the latest version, but it has not identified a specific CWP security patch that addresses the unknown initial intrusion method. Upgrading therefore should not be treated as proof that an attacker can no longer gain access.
Restricting administrative access to trusted networks and monitoring unexpected outbound connections can also reduce exposure.
What administrators still don't know
XLab has not identified the initial access method, named the attackers, or established how many servers are infected. The researchers also cannot confirm whether CWPdoor and the Ebury-associated malware found in the Brazilian sample are connected.
The available evidence supports treating a confirmed CWPdoor infection as a serious server compromise. Administrators should investigate how root access was obtained, not simply remove the modified web server and resume normal operations.
Clean logs and unchanged timestamps are particularly weak reassurance in this case. CWPdoor was designed to preserve both while giving attackers a hidden command channel.
Also read: A recent cPGuard supply-chain attack compromised nearly 3,000 Linux servers through poisoned security updates, leaving administrators to investigate privileged access and potentially stolen credentials.