OPSSHIELD zufolge verteilte der kompromittierte cPGuard-Updatekanal am 2. November 2026 ein Schadskript an Linux-Server. Betroffen waren demnach die Versionen 5.88.12 bis 5.88.19. Das Skript konnte eine Hintertür einrichten und sensible Dateien erfassen. Für Administratoren ist deshalb wichtig, Update-Protokolle zu prüfen und mögliche Zugangsdaten unabhängig von der Softwareaktualisierung zu erneuern.

Wie der Angriff auf den Updatekanal ablief

OPSSHIELDs spätere Darstellung zufolge erhielt der Angreifer am 1. November 2026 um 22:58 Uhr UTC Zugriff auf den Abrechnungs- und Lizenzierungsserver des Unternehmens. Am 2. November lud der Angreifer das Schadskript zwischen 02:04 und 02:09 Uhr UTC in das Update-System. Installationen auf Kundenservern soll es zwischen 02:08 und 03:20 Uhr UTC gegeben haben.

Der genaue Request, mit dem der Angreifer die Befehlsausführung auf dem Unternehmensserver erreichte, ließ sich laut OPSSHIELDs Darstellung nicht aus den Protokollen ablesen. Der Bericht beschreibt, dass der Angreifer einen Update-Schlüssel zum Hochladen des Skripts verwendete.

Welche Server möglicherweise ein betroffenes Update erhielten

Als betroffen galten cPGuard-Versionen 5.88.12 bis 5.88.19. Ein passender Eintrag im Installationsprotokoll kann zeigen, dass eine betroffene Aktualisierung installiert wurde. Er belegt für sich genommen jedoch nicht, dass das Skript ausgeführt wurde oder Daten den Server verließen.

Mit diesem Befehl lässt sich nach dem Update-Eintrag suchen:

grep 'Successfully updated' /opt/cpguard/logs/install_log

Auch fehlende oder unvollständige Protokolle schließen eine Ausführung laut OPSSHIELDs Hinweisen nicht aus. Dass nach einer Aktualisierung keine bekannten Artefakte mehr vorhanden sind, belegt ebenfalls nicht, dass das Skript nie lief.

Welche Dateien das Skript erfasste und zurückließ

Das Skript soll unter anderem /etc/shadow, /etc/passwd, SSH-Dateien von Root, /root/.my.cnf und den Shell-Verlauf von Root erfasst haben. Auf wenigen Servern soll es außerdem /root/.s3cfg gelesen haben. Welche Geheimnisse sich tatsächlich in den einzelnen Dateien befanden, kann je nach Server variieren.

Als Hinterlassenschaften wurden eine versteckte Shell unter /var/tmp/.cpg91511_sh, die Cron-Aufgabe /etc/cron.d/i93677 und Dateien unter /var/tmp/.i93677/ beschrieben. Weitere Pfade im Zusammenhang mit der Datensammlung waren /var/tmp/.cpg91511 und /var/tmp/.cpg91511/loot.tgz. Das Skript wurde als cpguard-v58812-i91511.sh sowie mit Varianten mit den Endungen b, c und d beschrieben.

Welche Auswirkungen OPSSHIELD meldete

OPSSHIELD schätzte in seiner späteren Darstellung, dass das Skript auf etwa 2.950 Kundenservern lief. Außerdem seien Abrechnungsdaten von rund 7.900 Kundenkonten entwendet und Kopien von drei OPSSHIELD-Cloudservern angefertigt worden.

Eine frühere Schätzung von 32 Dateien bezog sich auf Dateien vom Lizenzierungsserver, die jeweils einem Kundenserver zugeordnet waren. Diese Zahl beschreibt eine andere Größe als die spätere Schätzung der Server, auf denen das Skript lief.

Welche Schritte für möglicherweise betroffene Server genannt wurden

OPSSHIELD riet dazu, cPGuard zu aktualisieren, nach verbliebenen Dateien und Aufgaben zu suchen und anschließend potenziell betroffene Zugangsdaten und Schlüssel zu erneuern. Die Schritte erfüllen unterschiedliche Zwecke: Eine Softwareaktualisierung beseitigt keine Geheimnisse, die das Skript möglicherweise bereits kopiert hatte.

  1. cPGuard aktualisieren. Zunächst wurde Version 5.88.25 als Fehlerbehebung genannt. Spätere Angaben ordneten Version 5.88.26 die Entfernung der Hintertür zu. Ein separates Folgeupdate entfernt die Cron-Aufgabe.
  2. Nach verbliebenen Artefakten suchen. Dazu gehören die genannten Pfade und die Cron-Aufgabe. Ein fehlender Fund allein schließt eine frühere Ausführung nicht aus.
  3. Möglicherweise offengelegte Zugangsdaten erneuern. Dazu zählen lokale und wiederverwendete Passwörter, Datenbankzugänge, Cloud-Zugangsdaten, SSH-Schlüssel sowie Zugangsdaten für das OPSSHIELD-Abrechnungsportal. OPSSHIELDs Hinweise nennen außerdem die Prüfung von authorized_keys und das Entfernen alter, vertrauenswürdiger öffentlicher Schlüssel.

OPSSHIELD empfahl keinen routinemäßigen Neuaufbau des gesamten Betriebssystems. Das Unternehmen beschrieb eine Einzelfallprüfung und einen Neuaufbau aus einem sauberen Backup für Server, auf denen ein manueller Login des Angreifers bestätigt wurde.