cPGuard: Gekaperter Update-Kanal verteilt Root-Hintertür auf rund 2.950 Linux-Server

OPSSHIELD, Hersteller der Server-Sicherheitssuite cPGuard, meldet, dass ein Angreifer in seinen Abrechnungsserver eingedrungen ist und am 2. November 2026 mit einem gestohlenen Schlüssel ein gefälschtes Update veröffentlicht hat. Rund 70 Minuten lang lief das Skript als root auf Linux-Servern von Kunden, legte eine versteckte Shell an und kopierte Passwort-Hashes, SSH-Schlüssel und Datenbank-Zugangsdaten.

Was geschah

OPSSHIELD vertreibt cPGuard, eine Sicherheitssuite (Malware-Scanner, Firewall, Web Application Firewall) für Linux-Webhosting-Server. Am 3. November 2026 gab der Hersteller bekannt, dass sein Update-Kanal gekapert worden war. Laut seinem Vorfallbericht registrierte der Angreifer am 1. November unter falscher Identität ein Kundenkonto, bestellte eine kostenlose Testlizenz und nutzte dann eine Lücke in der Abrechnungsanwendung, um Befehle auf dem Abrechnungs- und Lizenzserver auszuführen. Mit einem gestohlenen Zugriffsschlüssel lud er von dort am 2. November kurz nach 02:00 Uhr UTC ein gefälschtes cPGuard-Update in den Update-Speicher.

Wer betroffen ist

cPGuard-Agenten installierten das gefälschte Update am 2. November zwischen 02:08 und 03:20 Uhr UTC, also in einem Fenster von etwa 70 Minuten. Das Skript lief als root, legte eine versteckte Shell an und schickte sensible Dateien an den Angreifer: /etc/shadow und /etc/passwd, die SSH-Schlüssel von root, authorized_keys und known_hosts, das MySQL-Root-Passwort aus /root/.my.cnf, die Shell-Historie von root und auf einigen Servern S3-Schlüssel aus /root/.s3cfg. OPSSHIELD beziffert die betroffenen Kundenserver auf rund 2.950. Zudem wurden die Daten von etwa 7.900 Konten des Abrechnungsportals offengelegt (Name, Firma, Postanschrift, E-Mail, bcrypt-Passwort-Hashes). Der Hinweis nennt die Versionen 5.88.12 bis 5.88.19.

Was jetzt zu tun ist

1. Jeden Server aktualisieren mit cpgcli update --start und mit cpgcli --version prüfen: OPSSHIELD verlangt mindestens 5.88.25, Version 5.88.26 entzieht zusätzlich den Support-Zugang.
2. Update-Historie prüfen mit grep 'Successfully updated' /opt/cpguard/logs/install_log. Eine Version zwischen 5.88.12 und 5.88.19 oder ein im Zeitfenster aktives cPGuard bedeutet: Server als kompromittiert behandeln.
3. Suchen und löschen: /var/tmp/.cpg91511_sh, /var/tmp/.cpg91511/, /etc/cron.d/i93677 und /var/tmp/.i93677/; außerdem die Logs nach der IP-Adresse 94.183.188.91 durchsuchen.
4. Passwörter zurücksetzen: root, alle lokalen Konten und jedes anderswo wiederverwendete Passwort.
5. SSH-Schlüssel von root ersetzen, alte öffentliche Schlüssel von allen Servern entfernen, die ihnen vertrauten, und authorized_keys überprüfen.
6. Rotieren: MySQL- und Datenbank-Passwörter, S3-Schlüssel sowie alle Token und Passwörter aus der Shell-Historie von root.
7. Passwort des OPSSHIELD-Portals ändern und Zwei-Faktor-Anmeldung aktivieren, auch wenn die eigenen Server nicht betroffen waren.
8. Bei Hinweisen auf manuelle Zugriffe den Server aus einer Sicherung von vor dem 1. November neu aufbauen.

Unsere Einschätzung

Ein Sicherheitsagent, der sich als root selbst aktualisiert, ist ein direkter Weg auf jeden Server, den er schützt: Die Infrastruktur seines Herstellers wird Teil der eigenen Angriffsfläche. Solche Agenten gehören inventarisiert, ihre Update-Quellen müssen bekannt sein, und Geheimnisse haben weder in der Shell-Historie noch in root-Dateien etwas verloren, die ein einziges Skript einsammeln kann.

Quellen

• OPSSHIELD — cPGuard security advisory: update channel compromise
• OPSSHIELD — Security incident disclosure
• OPSSHIELD — cPGuard changelog
• The Hacker News — cPGuard Update Channel Hijacked to Backdoor Linux Servers and Collect Password Hashes

Wie wir unsere Analysen auswählen, prüfen und schreiben →