CWPdoor: Hidden Backdoor in Control Web Panel Runs Commands Without Leaving Logs

CWPdoor backdoor hidden inside Control Web Panel's cwpsrv web server

Anyone running a Linux hosting server with Control Web Panel (CWP) should check one file this weekend. Researchers at QiAnXin's XLab have described a backdoor they call CWPdoor. It doesn't run as a separate piece of malware. Instead, it replaces the web server that powers the CWP admin panel itself, waits quietly for a signed request from the attacker, runs whatever command that request carries, and keeps the request out of the access logs.

What researchers found

CWP, formerly CentOS Web Panel, is a free control panel used to manage websites, DNS and email on Linux servers. Its admin interface runs on its own Nginx-based web server, cwpsrv. According to XLab's report, published November 5, 2026, attackers added malicious code to the cwpsrv source and recompiled it. The result works like the normal panel until it receives the trigger.

XLab first caught the installer on June 29, 2026. It was a script named cwpsrv_update.sh posing as a routine update. The script downloads a rebuilt cwpsrv for one of two versions, 1.15.10 or 1.24.0, and swaps it in. It then resets file timestamps and clears traces, so a quick look with ls or stat shows nothing unusual.

The backdoor only acts on requests with three custom headers starting with X-Ngx-Integrity: an encrypted command, a timestamp, and an RSA signature that binds the two together within a five-minute window. Because only someone holding the attacker's private key can produce a valid signature, other people can't simply take over the backdoor. A separate helper process runs the command, and the request never shows up in the access log.

Important context: this isn't a known CWP flaw

CWPdoor is not, on its own, a newly discovered vulnerability in CWP. Swapping out the cwpsrv binary requires root access, so the attackers must already control the server before they install it. XLab says it does not yet know how those servers were first compromised. Possible routes include stolen credentials, an older unpatched flaw, or another piece of malware, but none has been confirmed. Think of CWPdoor as a stealthy way for attackers to keep access to servers they already broke into.

Evidence it's being used against real servers

On September 30, 2026, someone in Brazil uploaded an archive to VirusTotal containing a CWPdoor sample alongside the long-running Ebury SSH backdoor. Most antivirus engines flagged Ebury, but when XLab checked the CWPdoor sample during its research it had zero detections out of 63 engines. That reflects a single scan at that time, and detection rates may have changed since. XLab concluded that "real victims already exist in the wild," though it hasn't said how many servers are infected, and it isn't clear whether the same group planted both pieces of malware. XLab also counted more than 340,000 CWP instances exposed to the internet in the past month. Those are potential targets, not confirmed infections.

How to check your server

XLab recommends three checks, run as root:

  • Unix socket: ss -axp | grep integrity. Any result mentioning ngx_http_integrity_helper is a red flag.
  • Processes: ps aux | grep cwpsrv. Look for helper processes you don't recognize that were started by cwpsrv.
  • Binary strings: strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity. A clean binary shouldn't contain these header names.

Security teams can also block or hunt for traffic to the download server XLab identified, 136.0.141[.]71, and compare file hashes against the indicators in XLab's report.

These checks are not exhaustive. They look for the specific CWPdoor build XLab analyzed. A negative result does not prove a server is clean, especially since the attacker needed root access to install the backdoor in the first place.

If you find it

  1. Isolate the host from the network, or restrict it tightly, so the attacker loses remote access.
  2. Preserve evidence before you change anything: take a disk or VM snapshot and copy the logs and the suspicious cwpsrv binary for investigation.
  3. Change credentials from a known-clean machine, never from the compromised server. That includes the CWP panel, root and SSH keys, hosted site and database passwords, and email and DNS accounts.
  4. Rebuild from a trusted image (the preferred option), then reinstall the latest CWP from official sources and restore only verified data. Because the attacker had root, don't rely on any file left on the host, including the cwpsrv.prev-* backup the installer may create.
  5. Check other servers that share credentials or SSH keys with the affected host for Ebury and other implants.

Why it matters

Hosting control panels hold the keys to every site, mailbox and DNS zone on a server. A backdoor that looks like a legitimate panel component, initially went undetected by antivirus engines and erases its own log entries could go unnoticed for months. For anyone running CWP, the quick checks above are worth doing now.

Sources: QiAnXin XLab; The Hacker News; BleepingComputer.

Post a Comment

0 Comments