As reported by The Hacker News, researchers at QiAnXin's XLab have disclosed a sophisticated backdoor — dubbed cwpdoor — embedded directly into the cwpsrv web server binary used by Control Web Panel (CWP), a free hosting management panel for Linux. The backdoored binary accepts commands via specially crafted HTTP requests signed with X-Ngx-Integrity headers and executes them without writing to access logs, making traditional log-based detection essentially useless.

Threat Alert: The attackers replace a legitimate system binary (cwpsrv) with a trojanized version that behaves identically until triggered by a signed request.

What Makes This Attack Notable

This is not a vulnerability in the traditional sense. There is no CVE to patch, no authentication bypass to fix. The attackers replace a legitimate system binary (cwpsrv) with a trojanized version that behaves identically until triggered by a signed request. This is a post-compromise persistence technique — the attacker already needs root access to install it. What makes it dangerous is how well it hides once in place:

What Makes This Attack Notable
Log evasion: Commands arrive via HTTP but are never logged, defeating SIEM correlation and web log monitoring.
Timestamp manipulation: The installer restores original file modification dates, so ls and stat show nothing unusual.
Low AV coverage: The sample had zero detections on VirusTotal at time of discovery, meaning endpoint AV and most EDR solutions would not flag it.
Targeted versions: The installer handles only cwpsrv 1.15.10 and 1.24.0, suggesting the operators have tested against specific deployments.

Threat Model and Attack Chain

The critical open question is how attackers obtain the initial root access required to install cwpdoor. XLab has not yet identified the initial access vector. However, given that CWP is widely deployed in shared hosting environments and budget VPS setups, several plausible paths exist:

  • Exploitation of known CWP or underlying system vulnerabilities (CWP has had security issues in the past)
  • Credential compromise via brute-force or credential stuffing on SSH or the panel itself
  • Supply chain compromise of update mechanisms
  • Another backdoor or rootkit already on the system providing the foothold
The Brazilian VirusTotal upload on September 30 and the June 29 capture date suggest active deployment in the wild. Organizations running CWP should assume potential compromise until verified clean — the low detection rate means traditional AV scans will not catch this.

Indicators of Compromise

TypeIndicator
MD5 (Installer)e505d4ffa21cf494a5dc2d7c8f4f1236
MD5 (cwpsrv 1.15.10)965aea67fb40de1bab5169ada993349f
MD5 (cwpsrv 1.24.0)d3f4e95113d49ab3991b45e457bda75b
C2 IP136.0.141[.]71
Socket Namengx_http_integrity_helper
Header PatternX-Ngx-Integrity*
Affected Versionscwpsrv 1.15.10, 1.24.0

Why This Matters Beyond CWP

This attack pattern — replacing a web server binary with a trojanized version that accepts signed commands — is not unique to CWP. Similar techniques have been observed in attacks on nginx, Apache, and other widely deployed server software. The lesson for defenders is broader: binary integrity verification is an underutilized control on Linux systems, and the combination of log evasion plus timestamp manipulation makes these backdoors extremely difficult to detect with standard tooling.

Hosting providers and MSPs running free control panels are particularly exposed. These environments often have less mature security operations, fewer integrity monitoring controls, and a higher likelihood of outdated software — all factors that make them attractive targets for this type of implant.

Shield53 Recommendations

Immediate Actions (Detection)

  • Socket check: Run ss -axp | grep integrity — the presence of ngx_http_integrity_helper indicates infection.
  • Process check: Run ps aux | grep cwpsrv and investigate any unexpected helper processes spawned by cwpsrv.
  • Binary check: Run strings /usr/local/cwpsrv/bin/cwpsrv | grep X-Ngx-Integrity — a positive result confirms the backdoor string is present in the binary.
  • Hash comparison: Compute MD5 of /usr/local/cwpsrv/bin/cwpsrv and compare against the known-bad hashes above.
  • Network check: Block and monitor for connections to 136.0.141.71 at perimeter firewalls and proxy logs.

Remediation

  • If infected, restore the original cwpsrv from the backup the installer creates at /usr/local/cwpsrv/bin/cwpsrv.prev-* — but do not stop there.
  • Assume full system compromise. If root-level backdoors were present, the attacker had full control. Rebuild from known-good media is the safest path. Patching the binary alone does not address other potential implants.
  • Rotate all credentials: SSH keys, panel passwords, database credentials, and any API tokens stored on the system.
  • Enable AIDE or OSSEC for file integrity monitoring on all critical binaries, not just cwpsrv.
  • Restrict outbound network access from the server — the backdoor must reach its C2 to function, and egress filtering would have blocked or at least alerted on the connection.

Preventive Measures

  • Deploy immutable infrastructure patterns where feasible — if the binary should not change, any change is an alert.
  • Implement network-level detection for anomalous HTTP headers (e.g., any X-Ngx-Integrity* headers in inbound traffic).
  • Segment management panels from production workloads — CWP and similar panels should not share a network namespace with sensitive services.
  • Consider whether free, community-supported control panels are appropriate for production hosting given the reduced security oversight compared to commercial alternatives.