Control Web Panel Backdoor: Check cwpsrv Now

QiAnXin XLab has documented cwpdoor, a Control Web Panel backdoor built into cwpsrv, the web server that runs the panel. Once an attacker already has root, the rebuilt binary executes commands sent in signed web requests and keeps those requests out of the access log.

What is the Control Web Panel backdoor?

The Control Web Panel backdoor is a rebuilt copy of cwpsrv, the web server behind Control Web Panel (CWP), a free panel for managing Linux hosting servers. QiAnXin’s XLab research team named it cwpdoor. The Hacker News, in a report by Swati Khandelwal, covered the research on November 6, 2026.

CWP, formerly CentOS Web Panel, is common on budget VPS plans and reseller accounts. cwpsrv answers the panel’s admin requests while customer sites keep serving pages as usual. The backdoor lives in the panel binary, usually at /usr/local/cwpsrv/bin/cwpsrv. A WordPress or Joomla owner who never logs into CWP is still exposed, because their files, databases and mail sit on that host.

XLab’s core finding is that the backdoor is cwpsrv itself, rebuilt with extra code. It behaves like the stock program until it is triggered. That places cwpdoor in a familiar lineage of trojanized trusted binaries: the vsftpd 2.3.4 backdoor of 2011, Ebury’s patched OpenSSH, and the SUNBURST code planted in SolarWinds Orion in 2020.

The report assigns no CVE, no CVSS score and no vendor patch. XLab describes a binary replaced by someone who already had root, not a remotely exploitable flaw in CWP. There is nothing to patch and forget. The real questions are whether the cwpsrv on disk is the build the vendor shipped, and how root was lost before the swap.

In hosting recoveries we handle, the panel password is rarely the whole loss. Root on a control panel reads every account, every database credential and the TLS private keys for every site on the box. A panel bug is one way to get there, as when a cPanel account became a root shell.

cwpdoor is the step after root: a way back in through a binary the admin already expects to see running.

How does cwpdoor run commands with no access log?

cwpdoor runs a command only when a request carries a valid timestamp and a valid signature in custom HTTP headers whose names begin with X-Ngx-Integrity. Otherwise it answers like ordinary cwpsrv. XLab says those triggering requests never appear in the access logs, so a quiet log and a live command channel can exist on the same host.

A helper component uses a named Unix socket, ngx_http_integrity_helper. Unix sockets live in the local socket table and need no new TCP port, which is why a port list looks like a stock CWP server, and the signed custom-header trigger weakens network scanning further. A sweep or fuzz of the panel without the signature gets normal pages back.

Nothing gives it away at a glance. Process listings still show cwpsrv, at the path administrators already know. There is no separate module dropped beside the panel, and a hunt for odd PHP files in theme or uploads folders will walk right past it.

When XLab checked, the backdoored cwpsrv had zero detections out of 63 on VirusTotal. That is a static scan for known byte patterns, and a daemon that is mostly legitimate code with a small added region often scores zero. Read the result as a limit of the method. Hash the file and compare it with a known-good build of the same version instead.

The signature check means a random visitor cannot fire the channel. That does not shrink the incident. The operator already had root, holds whatever the headers require, and can return as long as that cwpsrv stays in place. Reviewing Apache or nginx logs for the public sites misses the point: the hidden requests hit the panel web server, and even there they are left out.

Who can install cwpdoor, and are servers already hit?

Only someone who already has root. XLab does not know how attackers obtain it, and the write-up names no vulnerability, exploit chain or unauthenticated path into CWP. Any affected machine was fully compromised before cwpdoor arrived, so the job is much wider than updating a panel package.

XLab captured the installer on June 29; the write-up does not state the year for that date. The script, cwpsrv_update.sh, poses as a version update and handles only cwpsrv 1.15.10 and 1.24.0. A host running either of those two versions is exactly what the fake update was built to swap, and the file should be inspected even if the panel “looks updated.”

Built to fool a quick look

After the swap, the installer puts the file’s original dates back, so ls and stat show it as unchanged. That defeats a directory listing, not a hash. AIDE or Tripwire compare content, but cwpsrv usually sits outside the OS package database, so rpm or dpkg verification may have no checksum to offer.

XLab’s description of the installer also says it deletes “the temporary files and backup” after a successful swap. The restore copy, named cwpsrv.prev- followed by a date and time, may already be gone. Plan the cleanup as if it is.

Evidence of real victims

The sign that cwpdoor had left the lab came three months after the installer capture. On September 30, an archive holding a copy of the backdoor was uploaded to VirusTotal from Brazil. XLab reads that as evidence that “real victims already exist in the wild.” The researchers give no count of infected servers, no named customer and no sector.

Brazil is where the upload came from, not necessarily where the victim server sits. XLab also published indicators: three MD5 hashes for the installer and the two backdoored builds, one download-server address and three URLs on it. We leave those values out of this article. Take them straight from the QiAnXin XLab write-up so your hunt matches the original.

How do you check a CWP server without trusting open ports?

Check the Unix socket, the process list and the binary itself. Those are XLab’s three checks, and a list of open ports is not one of them. In the researchers’ example, the socket check found the backdoor on a server whose open ports looked normal.

Run these as root and keep the output with your incident notes:

• Socket: ss -axp | grep integrity. A result naming ngx_http_integrity_helper is a sign of infection.
• Processes: ps aux | grep cwpsrv. Look for unexpected helper processes started by cwpsrv.
• File: strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity. Those header names do not belong in a stock build.

A clean result on all three is a point-in-time check for this one implant, not a clean bill of health. Confirm which cwpsrv version you run before deciding the script could never have matched. If strings returns the header names, treat the binary as backdoored and stop making production changes on that host until you have a forensic copy.

Ignore the timestamps. Hash /usr/local/cwpsrv/bin/cwpsrv and compare it with a fresh install of the same version, or a copy you archived before the incident. Because the installer may delete its own backup, the replaced binary and the socket can be the only artifacts left. Copy the binary and image the disk before you clean anything.

Then look past the panel. With root, an operator can harvest /etc/shadow, SSH keys, the panel database and customer passwords, then leave a second implant these checks never see. The September 30 archive held cwpdoor and, separately, Ebury. On the hosted sites themselves, website malware scanning and protection covers the docroots; it does not replace these host checks.

What if the cwpsrv backup is already gone?

Then replace cwpsrv from a trusted build. XLab’s first cleanup step is restoring the original from the cwpsrv.prev- backup in /usr/local/cwpsrv/bin, but the installer may have deleted it. If the copy exists and you can show it predates the swap, use it. If not, never treat the backdoored file as a “previous” version.

Step two is upgrading to the latest version, then confirming that ss -axp | grep integrity returns nothing. Do it from a console you trust, after saving images, and repeat all three checks on the new binary. An update that leaves the old file in place, or gets swapped again by a surviving implant, changes nothing for the sites on that server.

Step three is treating the whole server as compromised. cwpdoor runs any command it receives, and its installer already had root. Change every control panel credential, then rotate SSH keys, database, mail and API passwords, and any DNS or registrar logins stored on the host. Reissue TLS certificates whose private keys lived there.

Hunt for other implants too, including webshells in customer docroots. We still find those beside panel-level access, the same kind of leftovers seen when attackers left webshells planted after PHP2Shell breaches.

If you cannot prove a restore source is genuine, rebuild: a fresh OS, a fresh panel install, and site content restored from a backup taken before the earliest sign of compromise, tested and scanned. It is slower than a file swap, and it is the option that survives a second backdoor in OpenSSH or a library preload.

Shared-hosting customers cannot rebuild the host. Ask the provider whether cwpsrv was checked for the integrity socket and X-Ngx-Integrity strings, whether it was replaced from a known-good build, and whether panel and database passwords were rotated. Vague reassurance that “the ports look normal” does not answer those questions. Change any WordPress, phpMyAdmin or SMTP password you reused elsewhere.

Is Ebury part of the same attack?

Nobody knows yet. Ebury sat in the same September 30 archive, but XLab does not claim one campaign. Ebury is an OpenSSH backdoor and credential stealer active since at least 2009. The researchers say they do not know whether the two are related, and that different attackers may have planted them on the same server.

Finding one implant is a reason to hunt for the other, and weak evidence of a single actor. Where the cwpdoor checks hit, review SSH the way Ebury cases are usually handled: hash sshd against the package that should be installed, read /etc/ld.so.preload, and look for unexpected libkeyutils libraries. An OpenSSH backdoor survives a cwpsrv reinstall and steals the new passwords you just set.

The open questions are clear. XLab does not know the initial root vector, names no operator and gives no infection count. Hosts on 1.15.10 and 1.24.0 have a concrete file to inspect. Every other CWP admin still needs to prove cwpsrv matches a known-good build and the integrity socket is absent. If the panel also runs customer DNS and mail, those are in scope as well.

FAQ

Is there a CVE for the Control Web Panel cwpsrv backdoor?

No. XLab describes a cwpsrv binary replaced by an attacker who already had root. The report gives no CVE, no CVSS score and no vendor patch version.

Which cwpsrv versions did the fake update script target?

The installer cwpsrv_update.sh, captured June 29, handles only cwpsrv 1.15.10 and cwpsrv 1.24.0. Check your version, then check the binary anyway.

Will antivirus on the server catch cwpdoor?

Not reliably. The sample XLab checked had zero detections out of 63 on VirusTotal. Use the socket, process and strings checks, and compare the file hash with a known-good build.

Does a normal-looking port list mean CWP is clean?

No. In XLab’s example the socket check found cwpdoor on a server whose open ports looked normal. The helper uses the Unix socket ngx_http_integrity_helper, which opens no new TCP port.

Should every password on the server be changed?

Yes. The backdoor can run any command, and installing it already required root. Rotate panel, SSH, database, mail, API and DNS credentials, and reissue TLS certificates whose keys lived on the host.

What should customers on shared CWP hosting ask their host?

Ask whether cwpsrv was checked for the integrity socket and X-Ngx-Integrity strings, whether the binary was replaced from a known-good build, and whether panel and database passwords were rotated afterward.

If the socket check hits, or the cwpsrv backup is already gone, treat every site on that server as exposed and get the content cleaned before traffic goes back on it. Once the host binary is replaced, SiteGuarding can handle the site cleanup and ongoing website protection.