Eine neue Linux-Hintertür mit dem Namen CWPdoor macht derzeit die Runde in den Bedrohungsberichten. Sicherheitsforschende von QiAnXin XLab haben sie nach Monaten stiller Beobachtung am 5. November 2026 öffentlich beschrieben. Die Besonderheit: Sie klinkt sich nicht als eigenständiger Prozess ins System ein, sondern ersetzt die Binärdatei des mit dem Control Web Panel (CWP) ausgelieferten Webservers cwpsrv. Dadurch führt sie Befehle aus, die über manipulierte HTTP-Anfragen hereinkommen – ohne dass diese Anfragen in den Access-Logs auftauchen. Für Betreiber von CWP-Installationen ist das eine ernste Nachricht. Allerdings ist CWPdoor kein frischer Zero-Day in Linux oder CWP, auch wenn das in manchen Schlagzeilen anklingt.

Wichtig für die Einordnung: Um CWPdoor überhaupt installieren zu können, brauchen Angreifer bereits Root-Zugriff auf den Server. Die Hintertür ist also kein Einstiegspunkt, sondern eine Persistenz-Werkzeug – sie verlängert den Zugriff und macht ihn unauffällig. Das ändert nichts daran, dass CWPdoor wegen des guten Verbergens besonders unangenehm ist, verschiebt aber die Dringlichkeit: Es geht darum, bereits kompromittierte Systeme zuverlässig zu finden, nicht primär um einen eiligen Patch.

Wie CWPdoor funktioniert

XLab hat die Backdoor erstmals am 29. Juni 2026 im hauseigenen CTIA-Sensorsystem gesichtet, eine Live-Probe von VirtualTotal datiert vom 30. September 2026. Ausgangspunkt ist ein Installationsskript namens cwpsrv_update.sh, das sich als normales Versions-Update tarnt. Es hält den cwpsrv-Dienst an, tauscht die Datei /usr/local/cwpsrv/bin/cwpsrv durch die manipulierte Version aus, setzt Zugriffs- und Änderungszeitstempel auf Werte aus der Vergangenheit und löscht per history -d die eigenen Spuren in der Bash-Historie. Danach läuft der Webserver scheinbar wie zuvor – gleiche Startparameter, gleiche Binärgröße, gleiche Reaktion auf Standard-Anfragen.

Der Trigger ist ein Dreigespann aus HTTP-Headern mit dem Präfix X-Ngx-Integrity. Trifft eine Anfrage mit gültigem Zeitstempel (±300 Sekunden Toleranz), einem AES-256-CBC-verschlüsselten Befehl und einer RSA-Signatur ein, führt CWPdoor den Befehl aus und schickt die Ausgabe verschlüsselt mit Content-Type application/octet-stream zurück. Der öffentliche Schlüssel liegt in der Binary, XOR-maskiert mit 0x55; der AES-Schlüssel ist der SHA-256-Hash dieses öffentlichen Schlüssels. Diese Mechanik soll Replay-Angriffe verhindern und sicherstellen, dass nur der ursprüngliche Operator die Backdoor ansprechen kann. Als Kommunikationskanal zwischen Haupt- und Hilfsprozess dient ein Unix-Domain-Socket mit dem Namen ngx_http_integrity_helper – das wohl eindeutigste Erkennungsmerkmal.

Symbolbild: Tux, das Linux-Maskottchen

Bild: Symbolbild für Linux-Serverumgebungen – betroffen sind in diesem Fall Systeme mit Control Web Panel. Tux von OpenClipart-Vectors (Pixabay), nach Tux-Design von Larry Ewing und The GIMP, Lizenz CC0, via Wikimedia Commons.

Wer betroffen ist

Die manipulierten Binärdateien decken laut XLab exakt zwei CWP-Versionen ab: cwpsrv 1.15.10 und 1.24.0. Wer eine andere Version einsetzt, ist von genau dieser Angriffskette nicht betroffen. Der Blick auf die Internet-Oberfläche macht trotzdem nachdenklich: XLabs Hunter-Plattform zählte im Zeitraum rund um die Veröffentlichung mehr als 340.000 im Netz erreichbare CWP-Instanzen. Das sind nicht automatisch Opfer – es sind potenzielle Ziele. BleepingComputer und The Hacker News bestätigen die Zahl in eigenen Zusammenfassungen, auch der österreichische CERT.at nennt den Fall im Tagesbericht vom 6. November 2026.

Der Infektionsweg bleibt offen. XLab hält fest, dass CWPdoor den Server nicht selbst öffnet – Angreifer haben ihn zuvor über andere Lücken übernommen. CWP hat in der Vergangenheit mehrfach durch kritische Schwachstellen auf sich aufmerksam gemacht, unter anderem im Jahr 2022 (CVE-2022-44877) und 2024 (CVE-2024-34459). Wer eine ältere CWP-Installation ohne regelmäßige Updates betreibt, ist für Vorab-Kompromittierungen anfälliger – und damit auch für Nachladeeffekte wie CWPdoor.

So prüfst du deinen CWP-Server

Der schnellste Test läuft über den Unix-Socket, den der Hilfsprozess der Backdoor anlegt. Melde dich als Root an und führe aus:

ss -axp | grep integrity
# alternativ bei älteren Systemen:
netstat -lxp 2>/dev/null | grep integrity

Taucht in der Ausgabe eine Zeile mit ngx_http_integrity_helper auf, ist das System mit sehr hoher Wahrscheinlichkeit kompromittiert. Plausibel ist zudem ein Blick auf die cwpsrv-Binärdatei:

md5sum /usr/local/cwpsrv/bin/cwpsrv
ls -la /usr/local/cwpsrv/bin/ | grep -i prev
stat /usr/local/cwpsrv/bin/cwpsrv

XLab veröffentlicht als Indicators of Compromise die MD5-Hashes e505d4ffa21cf494a5dc2d7c8f4f1236 (Installationsskript), 965aea67fb40de1bab5169ada993349f (cwpsrv 1.15.10 manipuliert) und d3f4e95113d49ab3991b45e457bda75b (cwpsrv 1.24.0 manipuliert). Stimmt der Hash deiner Binärdatei mit einem der letzten beiden überein, ist der Fall klar. Verdächtig ist außerdem eine Datei namens cwpsrv.prev-* im selben Verzeichnis – das Installationsskript legt sie als Backup des Originals an. Als Command-and-Control-Adresse nennt XLab 136.0.141.71; Firewall- und Proxy-Logs sollten auf Verbindungen zu dieser IP durchsucht werden.

Was du im Infektionsfall tun solltest

  • System als vollständig kompromittiert behandeln: Wer Root-Zugriff hatte, kann beliebige weitere Werkzeuge hinterlegt haben. Eine Neuinstallation ist der sicherste Weg, mindestens aber eine vollständige Forensik mit Live-Response-Werkzeugen.
  • Alle Zugangsdaten rotieren: SSH-Schlüssel, CWP-Admin, Datenbank-Passwörter, Mail-Konten, API-Tokens – alles, was auf dem Server lag oder von dort aus benutzt wurde. CWPdoor hat vollen Shell-Zugriff, also auch Zugriff auf alle lokal gespeicherten Geheimnisse.
  • Logs außerhalb des Servers prüfen: Die Access-Logs des cwpsrv selbst sind unzuverlässig. Besser: Reverse-Proxy-Logs, Firewall-Protokolle oder Cloud-Logs, die nicht auf dem betroffenen System liegen.
  • Autostart kontrollieren: systemd-Units in /etc/systemd/system/, cron-Jobs in /etc/cron.*, Einträge in /etc/rc.local und shell-Startskripte (.bashrc, .profile) sichten. CWPdoor arbeitet zwar in cwpsrv selbst, Angreifer legen aber häufig zusätzliche Persistenz an.
  • Updates einspielen und Dienste härten: Nur CWP-Versionen einsetzen, deren Changelog ihr versteht. Admin-Oberfläche hinter VPN oder zumindest IP-Allowlist stellen, Zwei-Faktor-Authentifizierung aktivieren.
  • Dateiintegrität automatisieren: Werkzeuge wie AIDE oder Tripwire schlagen Alarm, wenn sich Systembinärdateien unbemerkt ändern. Gerade bei schlanken Hosting-Setups ist das preiswert einrichtbar.

Einordnung

CWPdoor zeigt einen Trend, der sich seit zwei, drei Jahren verstärkt: Statt mit einem lauten Rootkit nachzuladen, verschmelzen Angreifer ihre Werkzeuge mit vorhandenen, legitimen Diensten. Der cwpsrv-Prozess war schon da, läuft als Root, bringt eigene Logs mit – ein perfekter Wirt. Für Verteidiger heißt das: Signaturbasierte Antiviren-Lösungen helfen hier kaum, auch bei Veröffentlichung registrierten gängige Engines die manipulierte Binary nicht als bösartig. Wer Shared-Hosting-Server betreibt, sollte einmal mehr prüfen, ob Dateintegritätsüberwachung, EDR-Lösungen für Linux und ein sauberes Hardening-Konzept installiert sind. Panik ist unangebracht, Aufmerksamkeit aber dringend geraten.

Quellen

Bildnachweis