Researchers have identified a Linux backdoor called CWPdoor that is being distributed through a trojanised version of cwpsrv, the web server used by Control Web Panel. The malware can remain passive until an attacker sends a specially constructed request, making it less likely to appear as an ordinary remote shell or noisy command channel. The campaign is relevant to hosting providers and administrators because a control panel often has broad visibility over websites, email, DNS and databases managed on the same server.
A trojanised CWP component provides the backdoor
According to researchers at XLab, the infection begins with a script posing as an updater. It replaces the legitimate cwpsrv binary with a malicious version. The researchers identified replacement activity involving cwpsrv versions 1.15.10 and 1.24.0. The script attempts to conceal the change by restoring file and directory timestamps, deleting temporary files and clearing command-history records. These steps aim to make a post-incident review more difficult because routine file metadata may no longer show when the binary was replaced.
CWPdoor can remain quiet
XLab describes CWPdoor as a passive backdoor. Rather than continuously opening a conspicuous remote connection, it waits for a specially crafted HTTP request containing encrypted command data. The request uses headers named X-Ngx-Integrity-Data, X-Ngx-Integrity-Time and X-Ngx-Integrity-Sig. The malware checks the timestamp and RSA signature before decrypting the command and passing it to a helper process. The researchers say the timestamp must fall within a five-minute window, which helps prevent replay of an old request.
The command and response data are protected using AES-256-CBC, according to the analysis. The malware also interferes with the server’s logging module so the triggering request does not appear in ordinary access logs. This combination makes detection more challenging: the operator does not need to maintain a persistent interactive session, and the request may be absent from the log administrators usually inspect first. A clean-looking access log is So not sufficient evidence that the panel binary is trustworthy.
The findings raise a software-integrity concern for hosts
XLab reported that more than 340,000 CWP instances had been exposed on the public internet over the preceding month. That is an exposure count, not a confirmed infection count. The researchers discovered the malware on 29 June after capturing the updater-like script. They later found a malicious cwpsrv sample uploaded to VirusTotal on 30 September in an archive that also contained the Ebury backdoor. The researchers said the sample’s lack of antivirus detections suggested the campaign was not merely experimental, although the relationship between CWPdoor and Ebury remains unclear.
XLab recommends checking for an ngx_http_integrity_helper Unix socket, suspicious cwpsrv helper processes and X-Ngx-Integrity strings in the server binary. These indicators should be treated as part of a broader investigation, not as a substitute for comparing the installed binary against a trusted package. Operators should inspect file hashes, package provenance, process trees, unexpected scheduled tasks, new accounts, outbound connections and changes to system startup configuration.
Keep the control panel and its operating system updated from trusted sources, restrict panel administration to known management networks and require strong authentication for administrator accounts. Where possible, place the panel behind a VPN or a zero-trust access gateway rather than exposing the administrative interface to the entire internet. Monitor changes to the cwpsrv executable and alert when a process or file appears outside the expected package lifecycle.
The researchers’ description points to a supply-chain problem inside a server-management product, rather than a conventional exploit against an exposed web application. A replacement of the legitimate service binary can survive routine checks if administrators rely only on timestamps or familiar process names. Verification should So include trusted package hashes, file integrity monitoring and investigation of unexpected helper processes, not simply a panel login or version check.