CWPdoor: Detect and Clean Up the Backdoor in Control Web Panel

Have your CWP servers checked? WZ-IT reviews Linux servers in a server audit and runs them with server management and CVE monitoring. A suspected compromise is classified separately. Book a meeting

On 5 November 2026 the XLab research team at QiAnXin published the backdoor CWPdoor in Control Web Panel (CWP, formerly CentOS Web Panel). It does not sit in an add-on file but in the panel's web server. Attackers added backdoor code to the cwpsrv source, recompiled it and replaced the original binary. The backdoor stays passive until a signed request arrives, and then leaves no entry in the access log. BleepingComputer and The Hacker News have picked up the report.

CWP is a hosting control panel for CentOS and other Linux distributions with a free edition; alongside it there is CWPpro. cwpsrv serves the interface used to manage websites, DNS and mail for the hosted accounts. Whoever controls this service can, depending on execution privileges, configuration and isolation, reach a large part of what the panel manages.

This article summarizes how CWPdoor works, what the version numbers mean, which commands check for an infection, where that check reaches its limits and what to do if you find a hit. All information is as of 9 November 2026. This case does not apply to cPanel; for cPanel see cPanel CVE-2026-41940.

Table of contents

1. Key Facts at a Glance
2. How CWPdoor Works
3. Which cwpsrv Versions Are Affected
4. What Is Still Unknown
5. Indicators at a Glance
6. Checking the Server: Commands for Admins
7. What a Clean Result Does Not Prove
8. If You Find a Hit: What to Do
9. Hardening CWP Servers
10. Hosting Panels as an Attack Target
11. Our approach at WZ-IT
12. Further guides

Key Facts at a Glance

Source: XLab, CWPdoor.

CWPdoor is not a vulnerability in CWP but an implant. The captured installer only runs with root privileges. Whether a separate root compromise comes first or an administrator runs the script as a supposed update is not known; XLab does not know the spread path. The backdoor then enables covert access to the server.

How CWPdoor Works

Installation. On 29 June 2026 XLab's capture system found the script cwpsrv_update.sh. It poses as a version update, runs only as root and supports only cwpsrv 1.24.0 and 1.15.10. The sequence according to XLab:

1. Check the local cwpsrv version, download the matching binary from 136.0.141.71 and verify the version of the downloaded file.
2. Back up the original binary, stop the service, overwrite /usr/local/cwpsrv/bin/cwpsrv and start the service.
3. Check that the master, worker and helper processes are running. If something fails, the script rolls the replacement back.
4. On success, delete the temporary files and the backup.
5. Reset access and modification time (atime and mtime) of the new binary and its parent directory to the original values, on success and on failure alike.
6. Clean the command history of the current session with history -d (see the note below).
7. Report the result to 136.0.141.71.

According to XLab, the replaced file therefore looks as if it was never modified under routine checks with ls and stat. That holds for atime and mtime: stat also shows the inode change time (ctime), which the reset does not cover (check step 6). XLab describes history -d as deleting the session history; according to the Bash manual, -d removes only a specified entry or range (-c clears the whole list). How completely the history is cleaned is therefore open.

Trigger. The attacker sends an HTTP request with three headers to the panel port. The check runs at the entry of request processing:

The AES key is the SHA-256 value of the embedded public key string; the public key sits XOR-obscured in the binary (byte 0x55). If the time or signature check fails, cwpsrv handles the request like normal traffic. XLab rates the binding of the three fields together with the 300-second window as replay protection and authorization. Whether the backdoor also discards requests it has already processed, the report does not describe; complete protection against repetition within the window is therefore not documented.

Execution and response. The master process decrypts the command and passes it through a Unix socket named ngx_http_integrity_helper to a separate helper child process. The result is returned AES-encrypted as HTTP 200 with the content type application/octet-stream. XLab does not state which privileges the helper runs with.

No trace in the log. For a triggering request the backdoor copies and modifies the request's context array and replaces the pointer of the logging module. The request is therefore not logged.

Three practical consequences:

• No reliable test from outside. Without a valid signature the server behaves like a normal cwpsrv. A valid signature can only be created by whoever holds the matching private key; an already signed request is sufficient within its time window. The check belongs on the server or on a secured copy of the binary.
• The access log is no proof of a clean server. An empty or unremarkable access log does not rule out use.
• Binary and host are the basis for checking. Socket, processes, strings, hash and outbound connections are the check points.

Which cwpsrv Versions Are Affected

Sources: versions and hashes from the XLab report, platform mapping from the CWP changelog (version 1.29).

The version numbers are the nginx base versions of the standard cwpsrv builds. The changelog for CWP 1.29 of 31 October 2026 states that cwpsrv was raised to nginx 1.30.6, from 1.24.0 on EL8/EL9 and 1.15.10 on EL7. This leads to an assessment XLab does not state explicitly: the installer targets the standard builds that CWP shipped before version 1.29. The version number therefore does not separate affected from unaffected: a replaced and an unmodified binary can carry the same version string. What matters is whether the binary on the server was replaced by the backdoored build.

Whether backdoored builds exist for other cwpsrv versions is open. XLab captured two samples.

According to the changelog, the current CWP version is 1.30.5 of 8 November 2026. Version 1.30.1 of 3 November 2026 is labelled a "security and stability update of the LTS version", and 1.30.2 the same day a security update. The changelog does not mention CWPdoor. An update makes sense, but it is no proof that a server is clean.

What Is Still Unknown

The VirusTotal upload is an indication of real cases. According to XLab, a file evidencia.tgz was uploaded from Brazil on 30 September 2026. It contained libkeyutils.so.1.5.2, which most vendors detect as the Ebury backdoor, and cwpsrv.suspeito, the CWPdoor binary, for which XLab reports zero detections. A single upload proves neither the number nor the scale of cases. According to BleepingComputer Ebury has been active since at least 2009; ESET documented the family in May 2024.

On the figure of 340,000: using QiAnXin's Hunter platform, XLab counts more than 340,000 CWP instances exposed to the internet over the month before the report of 5 November 2026. That is the number of possible targets, not a number of confirmed infections.

Indicators at a Glance

Source: XLab report including its IOC list. XLab publishes MD5 values only. The IP address is an indicator for outbound traffic, not for the attackers themselves. It can change or be taken offline.

Checking the Server: Commands for Admins

All commands run locally. Root or sudo is needed to fully map the processes and sockets of other users to their programs (depending on the /proc hidepid setting, other users' processes are visible without root as well); namespace boundaries and manipulated system tools can still limit the view. File checks such as strings and sha256sum work with read access to the binary. The commands are meant for read-only checking and make no repair or configuration changes but do leave traces: reads can update atime, sudo is logged depending on its configuration, and rpm -V can run a package's verification scripts; the rpm commands below therefore include --noscripts. If you suspect a compromise, save the output before intervening (see the next section).

1. The helper socket. This is XLab's main indicator.

sudo ss -axp | grep -i integrity

On a clean system nothing named ngx_http_integrity_helper appears. A hit with that name is a strong indicator of an active CWPdoor. The name is freely chosen, so the process and the executable (steps 2, 3 and 5) belong to the confirmation. The filter integrity is deliberately broad; the full name counts as the indicator.

2. cwpsrv processes. XLab names suspicious helper child processes of cwpsrv as an indicator.

ps -eo pid,ppid,user,lstart,args | grep '[c]wpsrv'

XLab does not document exactly what the process tree of a clean installation looks like. A comparison with an unsuspicious server of the same version helps.

3. Strings in the binary.

strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity

# without binutils:
grep -a -o 'X-Ngx-Integrity-[A-Za-z]*' /usr/local/cwpsrv/bin/cwpsrv | sort -u

A clean cwpsrv produces no output. Three hits (-Time, -Data, -Sig) are a strong indication of the backdoored build. A string match alone does not show that the code is executed; it justifies the investigation with the remaining steps.

4. Hash of the binary.

md5sum /usr/local/cwpsrv/bin/cwpsrv
sha256sum /usr/local/cwpsrv/bin/cwpsrv

# compare with the XLab values:
md5sum /usr/local/cwpsrv/bin/cwpsrv | grep -E '965aea67fb40de1bab5169ada993349f|d3f4e95113d49ab3991b45e457bda75b'

A hit matches one of the sample hashes published by XLab and is a very strong indication, provided the host and the check tools are not themselves manipulated. A missing hit proves nothing: attackers can use a different build, which yields a different hash. Note the SHA-256 value for the documentation and as a baseline.

5. The binary that is actually running. The path /usr/local/cwpsrv/bin/cwpsrv comes from the XLab report. Which file the process really executes is shown by /proc, regardless of the directory name. The loop covers all processes named exactly cwpsrv; if a process carries a different name, use the PID from step 2:

for pid in $(pgrep -x cwpsrv); do
  sudo ls -l /proc/$pid/exe
  sudo sha256sum /proc/$pid/exe
done

The suffix (deleted) after the path first of all means only that the path name of the running file was removed (unlink; proc_pid_exe(5)). Whether a replacement file sits at the same path shows by comparing the hashes of the path and of the running file. Replacing the file while the process runs, for example an update without a service restart, is one possible cause, but not the only one.

6. Timestamps (a hint, not proof). XLab describes the reset of mtime and atime; the report does not mention ctime. Resetting via utimensat(2) sets ctime to the current time (man page); the system interface does not allow setting ctime to an arbitrary value. An attacker with root can still falsify it, for example through the system clock or direct changes to the file system.

stat -c '%n | mtime %y | ctime %z' /usr/local/cwpsrv/bin/cwpsrv /usr/local/cwpsrv/bin

If ctime is clearly later than mtime, the inode was changed after the last content modification. That can be a reset mtime, but also a pure metadata change: changes to owner, mode or links update ctime without changing the content (inode(7)). This is our own inference, not an XLab indicator. A restore from a backup with preserved timestamps produces the same pattern. The finding is a reason for a closer look, not a verdict.

7. The installer's backup.

ls -la /usr/local/cwpsrv/bin/
find /usr/local/cwpsrv/bin -name 'cwpsrv.prev-*'

According to XLab the installer deletes the backup on success. Finding one does not fit the described success path and deserves a closer look; an empty result says nothing.

8. Traces on the network. The installer downloads from 136.0.141.71 and reports back to it.

grep -rIF '136.0.141.71' /var/log 2>/dev/null
sudo ss -tnp | grep -F 136.0.141.71

Firewall and flow logs of the network are more reliable than logs on the server, provided they are captured and protected independently of the server: an attacker with root can delete local entries. DNS logs do not capture direct connections to an IP address. Search them for the address across the entire available period.

9. Package verification, where applicable. The sources reviewed do not document whether cwpsrv is installed as an RPM package. This query shows whether a package owns the file:

rpm -qf /usr/local/cwpsrv/bin/cwpsrv

If rpm answers "is not owned by any package", the comparison with the local package database does not apply; a comparison with a trustworthy copy of the binary obtained externally remains possible. If a package owns the file, rpm -V --noscripts <package name> checks size, hash and other attributes against the RPM database (RPM manual). Whoever had root could also have changed that database; the result is an additional hint, not a substitute for a rebuild.

10. The library from the Ebury find. XLab found a manipulated libkeyutils in the same archive. On RPM-based systems, the package verification compares the library with the package:

ls -l /usr/lib64/libkeyutils*
rpm -V --noscripts keyutils-libs

No output from rpm -V --noscripts means no deviation of the checked files and attributes from the local RPM database. Any output needs assessment: a digest mismatch (a 5 in the line, not necessarily MD5) on libkeyutils is a serious finding and belongs in the incident review, whereas a changed time, owner or permissions can also have legitimate causes.

What a Clean Result Does Not Prove

The checks cover known indicators only; XLab publishes indicators for the two samples it captured. An empty result does not rule out other variants. That is our assessment, not a statement by XLab. Several things are missing for the conclusion "clean":

• Timing. When a server was infected cannot be read from these checks; forensic analysis can provide indications. The earliest documented point is the installer of 29 June 2026; older activity is not excluded.
• Other implants. Whoever had root may have created further access: SSH keys, users, cron jobs, systemd units, manipulated libraries. CWPdoor is only the part XLab knows.
• Antivirus. For the sample from the VirusTotal submission of 30 September 2026, XLab reports zero detections. A negative scan result is no proof of harmlessness anyway; signature-based scanners give no all-clear here.
• Logs. The triggering request is not in the access log, and the installer tries to clean the command history of its session.

The sensible approach is therefore to combine the checks above, a look at outbound traffic over a longer period and an assessment of whether third parties could previously have had root access: an unpatched panel version, shared or weak credentials, publicly reachable management ports.

If You Find a Hit: What to Do

For a confirmed infection XLab recommends three steps: restore the original binary, upgrade to the latest version and confirm that the socket check stays empty, and immediately rotate all control panel credentials and treat the host as compromised. The guide below goes further, because swapping the binary alone says nothing about the rest of the system.

1. Preserve evidence before changing anything. Take a snapshot or image of the system, store a copy of the binary with its hash, and save the output of ss -axp, ps and ss -tnp as well as the logs. Evidence-grade forensics is a discipline of its own; the steps here preserve the starting point for it.
2. Restrict reachability. Immediately block the ports on which cwpsrv listens for foreign networks. sudo ss -tlnp | grep cwpsrv shows which these are. Customer websites usually keep running through separate web server services; whether that applies to the specific server depends on proxy and forwarding configuration and needs to be clarified beforehand. According to the CWP changelog the panel, user panel and webmail run on cwpsrv ports and are no longer reachable through the blocked paths afterwards.
3. The installer's backup is not a reliable way out. XLab recommends restoring the backup cwpsrv.prev-<timestamp> created by the installer; it contains the original binary. The installer deletes that backup on success, though. If it is missing, the only option is a clean binary from a trustworthy source, best through a fresh installation of CWP. Even that does not change the root access attackers may have had before.
4. Rotate credentials. As a precautionary incident assumption, all secrets that were on the server or reachable through it count as compromised (XLab names the panel credentials): panel admin and root, SSH keys, database passwords (also in application configurations such as wp-config.php), passwords of hosting accounts and mail accounts, API tokens for DNS and provider, TLS keys. Rotate from a clean machine; order and timing depend on containment, because as long as the attackers' access exists they can read new values too.
5. Rebuild. Use a fresh operating system image, install CWP anew in the current version, then restore data. Restore websites, databases and mail, not binaries or configurations of the old system. Check restored data for web shells and foreign cron entries. This is WZ-IT's assessment: after a root takeover the integrity of the system cannot be demonstrated reliably with the host's own tools; a comparison with trustworthy external baselines or images would be possible, and the rebuild is the more reliable path. XLab words it more cautiously with the recommendation to treat the host as compromised.
6. Check reporting obligations. If the server holds personal data, a personal data breach may have occurred; storage alone does not trigger a notification. Then Art. 33 GDPR applies: the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to the rights and freedoms of natural persons. A processor (for example a host operating servers for customers) informs the controller without undue delay (Art. 33(2)). Where a high risk is likely, Art. 34 GDPR also requires informing the data subjects without undue delay; Art. 34(3) sets out exceptions with narrow conditions: encryption only if it makes the data unintelligible to unauthorized persons (doubtful after a root compromise where the keys are reachable), subsequent measures only if the high risk is no longer likely to materialize, and, for disproportionate effort, a public or similarly effective communication instead of individual notification. Every breach must be documented under Art. 33(5), even where no notification is made. The assessment depends on the individual case.
7. Check adjacent systems. If the credentials were used elsewhere, the other systems belong in the review: further servers, provider console, DNS management, password manager.

Hardening CWP Servers

The following measures apply regardless of the check result. They reduce the attack surface and make it easier to notice manipulation. They offer no guarantee of preventing or detecting attacks, in particular not against an attacker with root privileges.

Example of a monitoring rule with auditd: write and attribute changes in the binary's directory end up in the audit log provided the rule is loaded and effective: auditd must be running and auditing enabled, and exclusion rules or dropped events can prevent entries. The -w form is marked as deprecated in auditctl(8) (performance); the man page recommends syscall-based rules (-a always,exit with filters).

sudo auditctl -w /usr/local/cwpsrv/bin/ -p wa -k cwpsrv-bin
sudo ausearch -k cwpsrv-bin

A rule set with auditctl applies at runtime only and can be removed unless the audit configuration is locked (-e 2). For a permanent rule, put it into a file ending in .rules under /etc/audit/rules.d/; other files there are ignored. augenrules --load merges the files into /etc/audit/audit.rules and loads them into the kernel (augenrules(8)). For classifying the measures and further hardening of the system, see the Linux server hardening checklist.

A pure comparison against CVE numbers does not capture CWPdoor, because the sources reviewed name no CVE number. For such cases researcher and vendor reports, integrity checks and regular review of the indicators help.

Hosting Panels as an Attack Target

Hosting panels have properties that can make them attractive to attackers: one service usually runs with far-reaching privileges, is often reachable from the internet and manages many customer accounts at once. The examples show repeated attacks on hosting panels in recent years:

Sources: Facefish per the report by Juniper Threat Labs (report of 26 April 2021; the linked HPE page has been migrated and now shows a different date; first observed attack on 1 February 2021), the report by Netlab (27 May 2021) and The Record (28 May 2021); none names a CVE number for the flaw used. Catalog data per the NVD entries. XLab does not link any of the CWP flaws to CWPdoor; the table only shows that CWP has been actively attacked before.

The question behind this, how a panel daemon with root privileges on public ports can be operated securely, is covered at length in the article on the cPanel mass compromise. The CWPdoor case adds a second point: even a fully patched panel does not protect against an attacker who already has root. From WZ-IT's perspective, access paths, reachability of management ports and integrity monitoring therefore belong to running a panel as much as patching does.

Our approach at WZ-IT

With an indicator like CWPdoor, the work runs in five steps:

1. Determine exposure. Record the operating system, CWP version and reachability of the panel ports, and run the check commands above.
2. Contain. For a hit or suspicion, block the management ports and preserve the starting point before anything is changed. A suspected security incident is not part of the plannable basic audit. We review the request separately and agree the approach, availability and costs in advance.
3. Rotate credentials and rebuild. Rotation in a clean order, rebuild on a fresh system, restore and check data. Restoring production data takes place only with explicit approval or according to an agreed runbook.
4. Harden. Restrict management ports, set up updates and integrity monitoring, harden access.
5. Operate continuously. Add the system to monitoring, updates and CVE monitoring.

The server audit records the state of one standard Linux instance once, from €290 net: exposed ports and unnecessary services, patch level and known vulnerabilities, SSH, root and sudo configuration, firewall rules and indicators of common compromise patterns. Penetration testing and evidence-preserving IT forensics are not part of the basic audit.

Ongoing server management starts at €149.90 net per month for the first server and includes 24/7 monitoring, updates at agreed maintenance intervals, operating-system CVE monitoring, baseline hardening, backup management and central log collection. Debian, Ubuntu and RHEL derivatives such as AlmaLinux and Rocky Linux are daily business. Which applications such as a hosting panel are part of the scope in detail is defined before operations start. Management is remote and worldwide; the servers stay with the provider and under the customer's contract. CVE monitoring evaluates vendor advisories and distribution trackers.

Further guides

• cPanel CVE-2026-41940: mass compromise on shared hosting, why hosting panels are a structural risk and which alternatives exist.
• CVE monitoring for self-hosted software, how vulnerabilities are tracked in a structured way and where CVE feeds end.
• Linux server hardening: checklist based on CIS and BSI, SSH, firewall, accounts and logging with check commands.
• Linux patch management: process, deadlines and evidence, patch cycles and evidence for operations.
• Linux end of life: Debian, Ubuntu and CentOS support dates, support dates for operating systems such as CentOS 7.
• Linux kernel vulnerabilities 2026, patch management as a leadership task.
• Managed Operations, the hub with all offerings for operations, monitoring and CVE monitoring.
• SSHole (CVE-2026-123158): check OpenSSH on Alpine - another current security case (as of November 2026)
• Linux kernel TCP flaw CVE-2026-98432: patch Proxmox, Debian, Ubuntu - another current security case (as of November 2026)
• APT vulnerability CVE-2026-109518 in Debian and Ubuntu - another current security case (as of November 2026)
• Node-RED editor without adminAuth: CVE-2026-58115 (Siemens IoT2050) - another current security case (as of November 2026)

Have your CWP servers checked for CWPdoor? We record ports, patch level and access paths in the server audit, classify hits and suspected cases and, on request, take over ongoing operations. Book a meeting

Sources

• XLab (QiAnXin), CWPdoor: The Invisible Backdoor Living Inside Control Web Panel
• BleepingComputer, Hackers backdoor Linux servers using trojanized CWP web server
• The Hacker News, Hackers Hide Linux Backdoor in Control Web Panel Server
• eSecurityPlanet, CWPdoor Malware Detection and Removal
• webhosting.today, cwpdoor replaces Control Web Panel's web server
• Control Web Panel, Changelog
• Control Web Panel, Features
• NVD, CVE-2022-44877
• NVD, CVE-2025-48703
• NVD, CVE-2026-41940
• The Record, Malware campaign targets server hosting software CWP (Facefish, 2021)
• Juniper Threat Labs, Linux Servers Hijacked to Implant SSH Backdoor (Facefish, 2021)
• Netlab 360, Facefish (2021)
• ESET, Ebury is alive but unseen
• GNU Bash Reference Manual, Bash History Builtins
• Linux man-pages, inode(7)
• Linux man-pages, utimensat(2)
• Linux man-pages, proc_pid_exe(5)
• RPM, rpm(8)
• Linux man-pages, auditctl(8)
• Linux man-pages, augenrules(8)
• GDPR, Regulation (EU) 2016/679, Art. 33 and 34