cPGuard: Gekaperter Update-Kanal verteilt Hintertür und stiehlt Passwort-Hashes

Über den Update-Kanal des Server-Sicherheitswerkzeugs cPGuard ist am 2. November 2026 ein Schadskript an Linux-Server von Kunden verteilt worden. Laut der Sicherheitsmitteilung des Herstellers OPSSHIELD vom 3. November steckte das Skript in den cPGuard-Versionen 5.88.12 bis 5.88.19, installierte eine Hintertür und sammelte unter anderem /etc/shadow und /etc/passwd, die MySQL- oder MariaDB-Konfiguration von root, die Shell-Historie von root sowie dessen SSH-Dateien authorized_keys und known_hosts ein.

Betroffen sind Server, auf denen cPGuard läuft und die in diesem Zeitraum automatisch aktualisiert haben, typischerweise Webserver mit cPanel, DirectAdmin, Plesk oder anderen Panels. Das Update auf 5.88.25 entfernt die bekannten Dateien, entwertet aber keine bereits kopierten Zugangsdaten. Wer ein betroffenes Update im Log findet, sollte nicht auf ein Wartungsfenster warten.

Was ist passiert?

Nach Angaben von OPSSHIELD verschaffte sich ein unbekannter Angreifer am 2. November um 02:06 Uhr UTC mit kompromittierten Zugangsdaten Zugriff auf die Infrastruktur, über die der Hersteller Updates verteilt. Über diesen Weg ging das Skript an Kundenserver. Entdeckt wurde der Angriff laut OPSSHIELD innerhalb von zwölf Stunden nach Auslieferung der betroffenen Versionen.

Das Skript lud die gesammelten Daten auf einen Lizenzserver von OPSSHIELD hoch, und zwar über ein ebenfalls kompromittiertes Konto, von dem der Angreifer sie später abholen konnte. OPSSHIELD bestätigt, dass der Angreifer einen Teil der gesammelten Daten abgerufen hat, der Umfang wird noch untersucht. In einem Nachtrag in der Nacht zum 3. November schätzt der Hersteller, dass der Angreifer 32 gesammelte Dateien abgerufen hat, jede gehört zu einem Kundenserver. Das ist ausdrücklich eine vorläufige Schätzung der nachweislich abgerufenen Daten und nicht die Zahl aller möglicherweise betroffenen Server. Wie die Zugangsdaten für die Update-Infrastruktur in falsche Hände kamen, ist noch offen.

Wer ist betroffen?

Betroffen sind Server, die eine der Versionen 5.88.12 bis 5.88.19 installiert haben. Prüfen lässt sich das mit grep 'Successfully updated' /opt/cpguard/logs/install_log. Ein Eintrag mit einer dieser Versionen belegt die Installation, aber nicht, dass das Skript lief oder Daten abflossen. OPSSHIELD rät, solche Server trotzdem als möglicherweise kompromittiert zu behandeln, auch wenn sie inzwischen 5.88.25 oder neuer ausführen. Auch ohne passenden Eintrag, bei fehlendem oder unvollständigem Log ist der Server laut Hersteller nicht automatisch sauber.

Als bekannte Spuren nennt OPSSHIELD die Datei cpguard-v58812-i91511.sh, die Hintertür /var/tmp/.cpg91511_sh und das Sammelverzeichnis /var/tmp/.cpg91511 mit dem Archiv loot.tgz. Weil das Korrekturupdate die Hintertür und das Sammelverzeichnis entfernt, beweist das Fehlen dieser Spuren nach dem Update nichts.

Wie kritisch ist das?

Aus unserer Sicht gehört ein Lieferkettenangriff mit Datenabfluss und Hintertür zu den schwersten Fällen für einen Server. Die Passwort-Hashes aus /etc/shadow lassen sich offline angreifen, einfache oder bereits geleakte Passwörter sind dabei deutlich leichter zu knacken. Laut OPSSHIELD müssen aber auch starke Passwörter zurückgesetzt werden. Datenbankpasswörter in my.cnf und Geheimnisse in der Shell-Historie können dagegen im Klartext vorliegen, dort hilft kein Hash. Weitere Schadaktivität hat OPSSHIELD bisher nicht gefunden, nennt das aber ausdrücklich vorläufig. Einen kompletten Neuaufbau empfiehlt der Hersteller derzeit nicht als Regelfall, behält sich aber eine andere Bewertung vor.

Was sollten Admins jetzt tun?

• Inventar: alle Server mit cPGuard auflisten und je Server das Install-Log nach den Versionen 5.88.12 bis 5.88.19 durchsuchen.
• Update: cpgcli update --start ausführen und mit cpgcli --version prüfen, dass mindestens 5.88.25 installiert ist.
• Passwörter: auf betroffenen Servern root und alle anderen lokalen Konten mit Passwort aus einer vertrauenswürdigen Umgebung neu setzen, wiederverwendete Passwörter auch auf anderen Systemen ändern.
• Geheimnisse: Datenbankpasswörter, S3-Schlüssel, DigitalOcean-Token und alles, was in der Shell-Historie von root steht, austauschen.
• SSH: private Schlüssel unter /root/.ssh ersetzen und die alten öffentlichen Schlüssel auf allen Zielsystemen entfernen.
• Support-Zugang: Wurde der Support-Zugang von OPSSHIELD einmal freigegeben, liegt dessen öffentlicher Schlüssel in /root/.ssh/authorized_keys. Der Hersteller verteilt vorsorglich ein Update, das ihn entfernt, und hat nicht gesagt, ob der zugehörige private Schlüssel betroffen ist. Eine eigene Kontrolle der Datei ist aus unserer Sicht sinnvoll.

Einordnung für Unternehmen

Der Fall zeigt das Grundproblem von Sicherheitswerkzeugen mit Root-Rechten und automatischen Updates: Wer ihren Verteilweg übernimmt, erreicht in kurzer Zeit potenziell sehr viele Kundenserver. Für Hoster und Agenturen mit vielen Kundenservern ist die Rotation der Zugangsdaten der eigentliche Aufwand, nicht das Update. Aus unserer Sicht lohnt es sich, jetzt festzuhalten, welche Server Datenbank- oder Cloud-Schlüssel in der Shell-Historie haben, denn genau diese Werte schützt kein Hash.

Passende Anleitungen auf S-EDV

• VPS absichern und härten: UFW, SSH-Schlüssel und Fail2Ban unter Ubuntu und Debian
• Linux-Server härten nach CIS-Benchmark: Praxisplan für KMU (Debian/Ubuntu)
• CrowdSec mit Docker installieren: Community-IDS/IPS

Quellen

• OPSSHIELD: Sicherheitsmitteilung zur Kompromittierung des cPGuard-Update-Kanals
• The Hacker News: Bericht zum gekaperten cPGuard-Update-Kanal