Eigentlich soll das Linux-Sicherheitstool cPGuard Server vor Schadsoftware schützen. Jetzt ist genau dieses Programm selbst zum Einfallstor geworden: Unbekannte haben die Update-Infrastruktur des Herstellers OPSSHIELD übernommen und darüber manipulierte Updates verteilt. Laut Hersteller haben rund 2.950 Kundenserver das schädliche Update ausgeführt.
Der Angriff fand am 2. November 2026 statt und wurde am 3. November öffentlich bestätigt. Besonders gefährlich ist, dass die manipulierten Updates mit Root-Rechten ausgeführt wurden. Dadurch konnten die Angreifer unter anderem Passwort-Hashes, SSH-Schlüssel und Datenbankzugangsdaten sammeln. Wir erklären, welche cPGuard-Versionen betroffen sind, wie Du Deinen Server überprüfen kannst und warum ein einfaches Update möglicherweise nicht ausreicht.
cPGuard gehackt: Was ist genau passiert?
cPGuard ist eine Sicherheitslösung für Linux-Webserver. Das Tool erkennt Schadsoftware, verwaltet Firewalls und schützt Webanwendungen. Bei Hosting-Anbietern kommt es häufig zusammen mit Verwaltungsoberflächen wie cPanel, Plesk oder DirectAdmin zum Einsatz.
Am 3. November 2026 veröffentlichte der Hersteller OPSSHIELD einen ausführlichen Sicherheitsbericht. Daraus geht hervor, dass die Angreifer bereits am 1. November mit der Untersuchung des Kunden- und Lizenzportals begonnen hatten.
cPGuard-Sicherheitsupdate installieren
Nach dem Angriff auf die Update-Infrastruktur vom 2. November 2026 sollten alle cPGuard-Server auf den neuesten bereinigten Versionsstand aktualisiert werden.
cPGuard aktualisieren
Offizieller Aktualisierungsweg über die cPGuard-Kommandozeile:
cpgcli update --start
Installiere den jeweils aktuellen Stand aus dem regulären Herstellerkanal.
Installation überprüfen
Installierte cPGuard-Version anzeigen:
cpgcli --version
Historie auf betroffene Versionen prüfen:
grep 'Successfully updated' /opt/cpguard/logs/install_log
Zunächst registrierten sie ein eigenes Kundenkonto und installierten eine kostenlose cPGuard-Testversion. Anschließend nutzten sie Schwachstellen beziehungsweise unzureichend abgesicherte Abläufe im Abrechnungsportal, um Zugriff auf die Herstellerinfrastruktur zu erlangen.
Am 2. November verwendeten sie entwendete Zugangsschlüssel, um manipulierte Aktualisierungen über den regulären Updatekanal bereitzustellen. Das betraf cPGuard-Versionen von 5.88.12 bis einschließlich 5.88.19.
| Eigenschaft | Information |
|---|---|
| Betroffene Software | cPGuard für Linux-Server |
| Hersteller | OPSSHIELD |
| Beginn der Angriffe | 1. November 2026 |
| Manipulierte Updates | 2. November 2026 |
| Öffentliche Sicherheitswarnung | 3. November 2026 |
| Betroffene Updateversionen | 5.88.12 bis 5.88.19 |
| Bereinigungsupdate | Ab 5.88.25, aktualisierte Herstelleranleitung nennt 5.88.26 und weitere Nachbesserungen |
| Betroffene Kundenserver | Ungefähr 2.950 laut Hersteller |
| Betroffene Portalkonten | Ungefähr 7.900 |
| Angriffsart | Manipulierte Softwareaktualisierung, Backdoor und Datendiebstahl |
| CVE und CVSS | Keine eigenständige CVE-Kennung oder CVSS-Bewertung veröffentlicht |
Wichtig ist, diesen Vorfall nicht mit einer klassischen Sicherheitslücke im Programm selbst zu verwechseln. Hier wurde nicht cPGuard über einen Fehler im Code geknackt, sondern die Infrastruktur des Herstellers angegriffen. Deshalb spricht man von einem sogenannten Supply-Chain-Angriff: Ein eigentlich vertrauenswürdiger Software-Lieferweg wurde missbraucht.
Rund 2.950 Linux-Server erhielten manipulierte Updates
Die aktuelle Untersuchung des Herstellers zeichnet ein beunruhigendes Bild. Zwischen 02:08 Uhr und 03:20 Uhr UTC am 2. November führten cPGuard-Installationen manipulierte Updates aus. Diese Zeitangaben beziehen sich auf UTC und entsprechen 03:08 Uhr bis 04:20 Uhr deutscher Winterzeit.
Die Angreifer benötigten dafür keine direkte Anmeldung an jedem einzelnen Kundenserver. Die Schadsoftware wurde über den bereits eingerichteten und normalerweise vertrauenswürdigen Update-Mechanismus verteilt.
Nach Angaben des Herstellers wurde das manipulierte Update auf rund 2.950 Servern ausgeführt. Wie viele einzelne Dateien dabei von jedem Server übertragen und anschließend von den Angreifern abgerufen wurden, wird noch untersucht.
Betroffen waren außerdem etwa 7.900 Konten des Kundenportals. Laut OPSSHIELD wurden dabei persönliche Kontodaten und Passwort-Hashes entwendet. Auch diese Kunden sollten daher ihre Zugangsdaten ändern.
Welche Daten konnten die Angreifer stehlen?
Der schädliche Updatecode hatte einen besonders gefährlichen Vorteil: cPGuard wird auf Linux-Servern mit weitreichenden Systemberechtigungen betrieben. Dadurch konnte die manipulierte Aktualisierung auf sensible Bereiche zugreifen.
Nach den bisherigen Herstellerinformationen zielte der Schadcode unter anderem auf folgende Dateien und Informationen:
| Datei oder Verzeichnis | Mögliche Bedeutung |
|---|---|
/etc/shadow | Passwort-Hashes lokaler Linux-Konten |
/etc/passwd | Informationen zu lokalen Benutzerkonten |
/root/.ssh | Private SSH-Schlüssel und Informationen über erlaubte Verbindungen |
/root/.my.cnf | Konfigurationsdatei mit möglichen MySQL-Zugangsdaten |
| Root-Shell-Verlauf | Früher ausgeführte Befehle, möglicherweise mit Kennwörtern oder Tokens |
/root/.s3cfg | Mögliche Zugangsschlüssel für Cloud-Speicher |
Die Datei /etc/shadow enthält normalerweise keine Kennwörter im Klartext, sondern kryptografische Passwort-Hashes. Diese können jedoch unter Umständen durch Offline-Angriffe geknackt werden. Besonders gefährlich sind außerdem private SSH-Schlüssel und in Konfigurationsdateien gespeicherte Zugangsdaten.
Hat ein Angreifer einen verwendbaren SSH-Schlüssel kopiert, kann dieser möglicherweise auch für weitere Server eingesetzt werden. Deshalb muss die Untersuchung über den unmittelbar betroffenen cPGuard-Server hinausgehen.
Wie Du unter Windows sicher auf einen Linux-Server zugreifst, erklären wir in unserem Beitrag Windows und Linux-VPS sicher verbinden. Weitere Grundlagen zum verschlüsselten Dateitransfer findest Du in unserer Anleitung SFTP-Server unter Windows einrichten.
Backdoor auf Linux-Servern: Diese Spuren sind bekannt
Die Angreifer beschränkten sich nicht auf den einmaligen Datendiebstahl. Die manipulierten Updates legten außerdem Dateien ab, die einen späteren Zugriff auf den Server ermöglichen konnten.
Zu den vom Hersteller bestätigten Indikatoren gehören folgende Dateipfade:
| Indikator | Bedeutung |
|---|---|
/var/tmp/.cpg91511_sh | Versteckte Shell mit Root-Berechtigungen |
/var/tmp/.i93677/ | Verzeichnis mit verdächtigen Dateien |
/etc/cron.d/i93677 | Verdächtiger geplanter Auftrag |
cpguard-v58812-i91511*.sh | Manipulierte Update-Skripte |
Diese Hinweise sind vor allem für Administratoren und Sicherheitsteams wichtig. Allerdings entfernt eine korrigierte Version von cPGuard bereits bekannte schädliche Dateien. Findest Du sie danach nicht mehr, heißt das also nicht automatisch, dass Dein Server vorher sauber war.
Für eine vollständige Untersuchung solltest Du deshalb auch die Update-Historie und die Systemprotokolle prüfen und mögliche ungewöhnliche Verbindungen im Blick behalten.
cPGuard auf den Sicherheitsvorfall überprüfen: Schritt für Schritt
Wenn Du einen Linux-Server mit cPGuard betreibst, empfiehlt der Hersteller eine unmittelbare Überprüfung. Die wichtigsten Schritte lassen sich über eine SSH-Verbindung durchführen.
Schritt 1: Installierte cPGuard-Version anzeigen
Verbinde Dich zunächst mit Deinem Linux-Server und öffne ein Terminal. Mit folgendem Befehl lässt sich die installierte Version überprüfen:
cpgcli --version
Der Hersteller empfiehlt mindestens die bereinigte Version 5.88.25. Im erweiterten Sicherheitsbericht wird bereits Version 5.88.26 beschrieben. Zusätzlich wurden weitere Nachbesserungen angekündigt. Deshalb solltest Du nicht bei einer bestimmten älteren Korrekturversion stehen bleiben, sondern den aktuellen Herstellerstand installieren.
Schritt 2: Updatehistorie kontrollieren
Eine inzwischen aktualisierte Version bedeutet nicht, dass der Server während des Angriffszeitraums sicher war. Der Hersteller empfiehlt deshalb die Kontrolle der Installationshistorie:
grep 'Successfully updated' /opt/cpguard/logs/install_log
Achte besonders auf Einträge zu den Versionen 5.88.12 bis 5.88.19. Taucht dort ein solches Update auf, solltest Du den Server vorsorglich als möglicherweise kompromittiert behandeln.
Wichtig dabei: Der Logeintrag belegt erst einmal nur, dass eine betroffene Version installiert wurde. Er heißt nicht automatisch, dass wirklich alle genannten Daten abgeflossen sind. Umgekehrt ist ein fehlender Eintrag kein sicherer Beweis dafür, dass alles in Ordnung war – vor allem dann nicht, wenn Logdateien unvollständig sind.
Schritt 3: cPGuard aktualisieren
OPSSHIELD dokumentiert den folgenden offiziellen Aktualisierungsbefehl:
cpgcli update --start
Führe die Aktualisierung über eine vertrauenswürdige Administrationsverbindung aus. Kontrolliere anschließend erneut mit cpgcli --version den tatsächlichen Versionsstand.
Falls das Update nicht erfolgreich abgeschlossen wird oder die Bereinigung nicht bestätigt werden kann, solltest Du den Hersteller-Support kontaktieren und keine fremden Reparaturskripte aus unbekannten Quellen verwenden.
Schritt 4: Bekannte Backdoor-Dateien überprüfen
Die vom Hersteller genannten verdächtigen Dateien lassen sich beispielsweise mit folgendem Befehl kontrollieren:
sudo ls -ld /var/tmp/.cpg91511_sh /var/tmp/.i93677 /etc/cron.d/i93677 2>/dev/null
Werden noch verdächtige Dateien gefunden, solltest Du vorhandene Beweise sichern und die vollständige Bereinigung planen. Bei einem ernsthaften Kompromittierungsverdacht empfiehlt sich die Prüfung aus einer vertrauenswürdigen Wiederherstellungsumgebung, da Schadsoftware auf einem laufenden System Untersuchungsergebnisse verfälschen kann.
Warum ein cPGuard-Update allein nicht ausreicht
Besonders wichtig: Eine neue Softwareversion kann bekannte Backdoors und schädliche Dateien entfernen. Bereits kopierte Kennwörter und private Schlüssel werden dadurch aber nicht automatisch ungültig.
Hat ein Server das manipulierte Update ausgeführt – oder lässt sich das nicht ausschließen –, müssen die möglicherweise offengelegten Zugangsdaten ersetzt werden.
Welche Kennwörter und Schlüssel sollten geändert werden?
- Setze das Root-Kennwort und die Kennwörter aller betroffenen lokalen Linux-Konten über eine vertrauenswürdige Verwaltungs- oder Wiederherstellungsumgebung zurück.
- Erzeuge neue SSH-Schlüssel und entferne die alten öffentlichen Schlüssel aus allen Systemen, die diese bisher akzeptiert haben.
- Ändere betroffene MariaDB- und MySQL-Zugangsdaten.
- Ersetze möglicherweise offengelegte Cloud-Schlüssel, API-Tokens und andere Geheimnisse.
- Kontrolliere weitere Server, auf die über die bisherigen SSH-Schlüssel zugegriffen werden konnte.
- Ändere das Kennwort für das OPSSHIELD-Kundenportal und aktiviere eine zusätzliche Anmeldeabsicherung.
Wenn Du bei einem SSH-Schlüsselwechsel Unterstützung benötigst, sind die Grundlagen zur Schlüsselverwaltung auch für Windows-Administratoren interessant. Unsere Anleitung zum SFTP- und OpenSSH-Zugriff unter Windows erklärt die wichtigsten Bestandteile.
Besonders sorgfältig solltest Du Systeme prüfen, die gemeinsame Zugangsdaten oder SSH-Schlüssel verwenden. Ein einzelner kompromittierter Hosting-Server kann sonst auch weitere IT-Systeme gefährden.
Müssen betroffene Server vollständig neu installiert werden?
Nach dem aktuellen Stand der Ermittlungen rät OPSSHIELD davon ab, alle betroffenen Server pauschal neu zu installieren. Der Hersteller empfiehlt zunächst, die Sicherheitskorrektur einzuspielen, den Server gründlich zu überprüfen und gefährdete Zugangsdaten auszutauschen.
Diese Einschätzung ist allerdings vorläufig. Werden unbekannte Backdoors, auffällige Administratorzugriffe oder andere Hinweise auf eine weitergehende Kompromittierung entdeckt, kann eine vollständige Wiederherstellung aus einem vertrauenswürdigen Backup nötig werden.
In virtualisierten Umgebungen ist es deshalb besonders wichtig, saubere Sicherungsstände und die Wiederherstellungsmöglichkeiten zu kennen. Grundlegende Informationen dazu findest Du in unserem Beitrag Windows Server Backup und Hyper-V.
Sind auch Windows-Server und WordPress-Websites betroffen?
cPGuard ist eine Sicherheitssoftware für Linux-Systeme. Windows 11 oder Windows Server werden durch diesen konkreten Angriff nicht unmittelbar über Windows Update kompromittiert.
Allerdings verwalten viele Windows-Administratoren Linux-Webserver, auf denen WordPress-Websites, Datenbanken oder andere Unternehmensdienste laufen. Ein solcher Server kann also durchaus Teil einer hauptsächlich auf Windows basierenden IT-Infrastruktur sein.
WordPress-Websites auf betroffenen Hosting-Servern sollten ebenfalls überprüft werden. Der cPGuard-Vorfall ist unabhängig von den jüngsten Sicherheitsproblemen innerhalb von WordPress selbst. Darüber berichten wir in WordPress 7.1.4 schließt gefährliche Sicherheitslücken.
Auch unser Beitrag zum UpdraftPlus-Sicherheitsvorfall zeigt, dass kompromittierte Zugangsdaten und zuvor installierte Hintertüren bei der Wiederherstellung besonders beachtet werden müssen.
Für Entwickler, die mit Linux-Containern unter Windows arbeiten, sind außerdem die Grundlagen von Docker unter Windows und dem Windows Subsystem für Linux interessant. Eine gewöhnliche lokale Docker- oder WSL-Installation ist allerdings nicht allein deshalb von diesem cPGuard-Angriff betroffen.
Was Administratoren aus dem cPGuard-Angriff lernen können
Der Vorfall zeigt: Ein Risiko geht nicht nur von öffentlich erreichbaren Anwendungen aus, sondern auch von Softwareaktualisierungen. Gerade Sicherheits-, Backup- und Verwaltungsprogramme haben oft besonders weitreichende Berechtigungen.
In der Praxis sind deshalb vor allem drei Punkte wichtig: Updates sollten nachvollziehbar aus vertrauenswürdigen Quellen stammen, administrative Zugangsdaten sollten möglichst nicht unnötig zwischen Systemen wiederverwendet werden – und Sicherheitsprotokolle sollten auch außerhalb des jeweiligen Servers verfügbar sein.
Außerdem ist es sinnvoll, Wiederherstellungen regelmäßig zu testen. Ein Backup schützt nicht ausreichend, wenn es dieselben kompromittierten Zugangsdaten verwendet oder sich auf einem ebenfalls angegriffenen System befindet. Wie sich beispielsweise regelmäßige Sicherungen von Webseiten erstellen lassen, erläutern wir im Beitrag Automatisierte WordPress-Backups unter Windows.

FAQ: Häufige Fragen zum cPGuard-Sicherheitsvorfall
Welche cPGuard-Versionen sind vom Angriff betroffen?
Die manipulierten Aktualisierungen wurden mit den Versionen 5.88.12 bis einschließlich 5.88.19 verteilt. Der Hersteller empfiehlt ein sofortiges Update auf den aktuellen bereinigten Versionsstand.
Wie viele Server sind vom cPGuard-Angriff betroffen?
Nach den aktuellen Herstellerangaben haben ungefähr 2.950 Kundenserver das manipulierte Update ausgeführt. Welche Daten von jedem einzelnen Server tatsächlich entwendet wurden, wird weiterhin untersucht.
Reicht die Aktualisierung auf cPGuard 5.88.26 aus?
Nein. Das Update beseitigt bekannte schädliche Dateien. Bereits kopierte Zugangsdaten, private SSH-Schlüssel und Kennwörter können aber weiterhin verwendet werden. Deshalb müssen möglicherweise kompromittierte Zugangsdaten zusätzlich ersetzt werden.
Wurden beim cPGuard-Angriff Kennwörter gestohlen?
Der Schadcode sammelte unter anderem Linux-Passwort-Hashes sowie möglicherweise in Konfigurationsdateien und Befehlsverläufen gespeicherte Zugangsdaten. Auch private SSH-Schlüssel gehörten zu den angegriffenen Informationen.
Sind Windows 11 und Windows Server direkt betroffen?
Nein. Der Angriff betraf die cPGuard-Update-Infrastruktur für Linux-Server. Windows-Systeme können allerdings mittelbar betroffen sein, wenn gemeinsame Zugangsdaten oder vertrauenswürdige Verbindungen zu kompromittierten Servern bestehen.
Gibt es eine CVE-Nummer für den cPGuard-Angriff?
Für diesen konkreten Angriff auf die Update-Infrastruktur wurde zum Zeitpunkt der Veröffentlichung keine eigenständige CVE-Kennung oder CVSS-Bewertung bestätigt. Die tatsächliche Kompromittierung und der Datendiebstahl sind jedoch vom Hersteller dokumentiert.
Fazit: cPGuard-Server sofort überprüfen und Zugangsdaten austauschen
Der Angriff auf cPGuard gehört zu den auffälligsten Sicherheitsvorfällen Anfang November 2026. Unbekannte Täter haben ein eigentlich vertrauenswürdiges Sicherheitstool missbraucht und so auf zahlreichen Kundenservern Schadcode mit Root-Rechten ausgeführt. Besonders gefährlich ist, dass dabei SSH-Schlüssel, Datenbankkennwörter und weitere administrative Zugangsdaten abgeflossen sein könnten.
Für betroffene Administratoren besteht deshalb unmittelbarer Handlungsbedarf. Kontrolliere die Updatehistorie, installiere die aktuelle bereinigte cPGuard-Version und tausche gefährdete Zugangsdaten aus. Prüfe außerdem, ob weitere Systeme denselben Schlüsseln vertrauen. Die ausführliche technische Darstellung, die aktuellen Indikatoren und die konkreten Herstellerempfehlungen findest Du im offiziellen OPSSHIELD-Sicherheitsbericht vom 3. November 2026.

Neueste Kommentare