Supply-Chain-Angriff: GitHub Actions als Waffe gegen cPanel-Server

Veröffentlicht am 28.07.2026

Angreifer haben aus GitHub ein gigantisches, kostenloses Angriffsnetzwerk gebaut – und richten es gezielt gegen cPanel- und WHM-Server. Über einen kompromittierten Entwickler-Account schleusten sie 583 bösartige Automatisierungs-Dateien in zehn weit verbreitete PHP-Pakete. Diese Dateien starten auf GitHubs eigenen Servern automatisierte Programme, die das gesamte Internet nach verwundbaren Webhosting-Servern absuchen und diese über die kritische Schwachstelle CVE-2026-41940 kapern. Wer eine Website auf einem cPanel-basierten Server betreibt – und das betrifft in Deutschland sehr viele KMU – sollte jetzt handeln.

Was ist passiert?

Zwischen dem 12. und 13. Juli 2026 übernahmen unbekannte Angreifer den GitHub-Account des legitimen PHP- und DevOps-Entwicklers „dinushchathurya“. Statt wie üblich Schadcode direkt in die Software einzubauen, wählten sie einen ungewöhnlichen Weg: Sie injizierten insgesamt 583 bösartige GitHub Actions Workflow-Dateien (das sind Automatisierungs-Anweisungen im YAML-Format, die auf GitHub bei bestimmten Ereignissen automatisch ausgeführt werden) in zehn Pakete auf Packagist – der zentralen Registrierungsstelle für PHP-Bibliotheken, aus der Entwickler weltweit ihre Bausteine beziehen.

Das Perfide daran: Der Schadcode steckt nicht im eigentlichen PHP-Programmcode, sondern ausschließlich in den Automatisierungs-Dateien unter dem Verzeichnis .github/workflows/. Packagist synchronisierte die manipulierten Entwicklungsversionen (die sogenannten „dev-main“-Versionen) am 13. Juli automatisch. Damit waren die 583 Schaddateien mit einem Schlag aktiv.

Die Sicherheitsforschungsfirma Socket entdeckte die Kampagne und veröffentlichte am 22. Juli 2026 ihren Analysebericht; The Hacker News berichtete am 23. Juli. Der GitHub-Account des Entwicklers wurde gesperrt. Doch die Kampagne gilt weiterhin als fortlaufend – Forks, Mirrors und andere kompromittierte Repositories können nach wie vor aktiv sein.

„Die PHP-Bibliotheken waren nicht der Ausführungspfad. Die Angreifer hatten Dutzende bösartige GitHub-Actions-Workflows in die Quell-Repositories des kompromittierten Maintainers eingefügt.“ – Socket (Sicherheitsforschungsunternehmen)

Wie funktioniert der Angriff technisch?

Der Ablauf ist raffiniert und zeigt, wie legitime Cloud-Infrastruktur zweckentfremdet wird. Die bösartigen Workflows starten auf GitHubs eigenen, kostenlos bereitgestellten Ubuntu-Servern (sogenannten „Runnern“). Diese Runner:

1. erkennen die Prozessorarchitektur des Systems (32/64-Bit x86, 32/64-Bit ARM),
2. laden ein passendes Linux-Angriffsprogramm vom Steuerungsserver der Angreifer (Command-and-Control-Server, IP-Adresse 43.228.157.68) herunter,
3. scannen daraufhin das gesamte Internet nach cPanel- und WHM-Servern, die für CVE-2026-41940 anfällig sind,
4. und übertragen erbeutete Daten alle 30 Sekunden per HTTP-POST-Anfrage zurück an den Steuerungsserver.

Der konkrete Scan-Befehl lautet dabei: /tmp/.svc ipscan --source random,all --exploit CVE-2026-41940 --git --envdump --ports 80,443,8080,8443,2082,2083,2086,2087. Die Angreifer nutzen GitHub damit als verteiltes, kostenloses Exploit-Netzwerk. Eine GitHub-Code-Suche nach dem eindeutigen Kennzeichen der Kampagne ergab rund 6.100 übereinstimmende Workflow-Dateien; breitere Suchen nach der C2-Adresse und der Exfiltrations-Logik lieferten sogar 15.000 bis 16.000 Treffer.

Was macht CVE-2026-41940 so gefährlich?

CVE-2026-41940 ist eine kritische Schwachstelle mit der höchstmöglichen Einstufung nahe dem Maximum (CVSS 9.8). Es handelt sich um einen Authentication Bypass – also eine Umgehung der Anmeldung – im HTTP-Basic-Auth-Handler des cPanel-Daemons cpsrvd. Zugrunde liegt eine sogenannte CRLF-Injection (das Einschmuggeln von Zeilenumbruch-Steuerzeichen in Eingabefelder).

Vereinfacht gesagt: Der Angreifer sendet einen manipulierten Anmelde-Header, dessen Inhalt versteckte Zeilenumbrüche und darin eingeschmuggelte Schlüssel-Wert-Paare enthält – etwa user=root, hasroot=1 und tfa_verified=1. Weil eine Filterfunktion auf diesem Code-Pfad nicht aufgerufen wird, schreibt der Server diese Angaben ungeprüft in eine Vor-Anmelde-Sitzungsdatei. Beim nächsten Verarbeitungsschritt werden die eingeschmuggelten Zeilen dann als echte Sitzungs-Attribute interpretiert.

Das Ergebnis: Der Angreifer wird als authentifizierter Root-Administrator behandelt – ohne Passwort und mit umgangener Zwei-Faktor-Authentifizierung, denn auch tfa_verified=1 wurde direkt gesetzt. Damit erlangt der Angreifer die vollständige Kontrolle über den Server.

„Die Kompromittierung von cPanel unterscheidet sich grundlegend von der Kompromittierung einer einzelnen Kunden-Website. WHM gewährt Root-Administratorzugriff auf den Server. Ein Angreifer mit diesem Zugriff kann jedes Kunden-Hosting-Konto lesen, Dateien und Datenbanken verändern, Backdoor-Konten anlegen, Malware installieren, Zugangsdaten stehlen und in Kundennetzwerke vordringen.“ – Hadrian (Sicherheitsunternehmen)

Erfolgreich gekaperte Server durchsuchen die Angreifer nach allem, was sich zu Geld machen oder für Folgeangriffe nutzen lässt: AWS-Keys, GitHub- und GitLab-Tokens, OpenAI- und Google-API-Zugangsdaten, Stripe-, SendGrid- und Mailgun-Keys, Datenbankzugangsdaten, SSH-Material und Git-Remotes.

Wer ist betroffen?

Betroffen sind grundsätzlich alle ungepatchten cPanel- und WHM-Versionen vor dem Fix für CVE-2026-41940 (laut Hersteller alle Versionen nach 11.40) sowie die manipulierten dev-main-Versionen der PHP-Pakete des Entwicklers „dinushchathurya“.

Die Dimension ist erheblich: Laut Shodan-Telemetrie von Rapid7 sind rund 1,5 Millionen cPanel-Instanzen mit dem Internet verbunden; Eye Security identifizierte im April 2026 sogar über 2 Millionen. cPanel kontrolliert laut W3Techs rund 94 % des Marktes für Webhosting-Kontrollpanele. Besonders gefährdet sind:

• KMU mit eigenem (V)Server und cPanel/WHM, die automatische Updates deaktiviert haben oder veraltete Versionen einsetzen;
• Websites auf Shared-Hosting-Plattformen, die von einem kompromittierten WHM-Server verwaltet werden;
• PHP-Entwickler, die die dev-main-Versionen der betroffenen Packagist-Pakete einsetzen.

Deutschland ist dabei nicht am Rand. Laut XLab/QiAnXin waren im Mai 2026 mehr als 2.000 Angreifer-IPs weltweit aktiv – hauptsächlich aus Deutschland, den USA, Brasilien und den Niederlanden.

So prüfen Sie, ob Sie betroffen sind

1. cPanel-Version prüfen: Per SSH auf dem Server einloggen und /usr/local/cpanel/cpanel -V ausführen. Liegt die Version unterhalb der gepatchten Versionen (z. B. unter 11.110.0.97 für den 11.110-Branch), ist der Server potenziell verwundbar.
2. Hosting-Provider kontaktieren: Bei Managed Hosting (etwa Strato, IONOS, All-Inkl, Hetzner) nachfragen, ob der Server bereits gepatcht wurde und ob Anzeichen einer Kompromittierung vorliegen.
3. Detection-Script ausführen: Das offizielle cPanel-Prüfskript ioc_checksessions_files.sh von support.cpanel.net herunterladen und als root ausführen. Es prüft Sitzungsdateien in /var/cpanel/sessions/ auf Kompromittierungsindikatoren (IOCs).
4. Sitzungsdateien manuell prüfen: Mit dem Befehl grep -lE "^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1" /var/cpanel/sessions/raw/* 2>/dev/null lassen sich verdächtige Einträge aufspüren.
5. Packagist-Abhängigkeiten prüfen: In PHP-Projekten die Dateien composer.json und composer.lock auf betroffene Pakete (dinushchathurya/*) untersuchen. Insbesondere dev-main-Versionen sind betroffen.
6. GitHub-Repositories prüfen: In eigenen Repositories nach Workflow-Dateien unter .github/workflows/ suchen, die die C2-Adresse 43.228.157.68 oder den Kampagnen-Identifier f5b0b742-240a-4811-8a5b-b0ba6060685d enthalten.
7. Persistenz-Mechanismen prüfen: Root-Cron-Jobs (crontab -l), SSH-Authorized-Keys (/root/.ssh/authorized_keys), unbekannte Prozesse und neu installierte Pakete im Expositionszeitraum untersuchen.

Das müssen Sie jetzt tun

1. Sofort patchen: cPanel/WHM aktualisieren mit /scripts/upcp --force, danach den Dienst neu starten mit /scripts/restartsrv_cpsrvd --hard. Bei Managed Hosting den Provider zur sofortigen Aktualisierung auffordern. Für CentOS 6 / CloudLinux 6 mit v110.0.50 steht v110.0.103 bereit.
2. Ports einschränken: Die cPanel/WHM-Ports (2082, 2083, 2086, 2087, 2095, 2096) auf Firewall-Ebene auf bekannte Admin-IP-Adressen beschränken. Diese Ports sollten niemals offen für das gesamte Internet sein. Als Übergangsmaßnahme bis zum Patch können sie komplett blockiert oder cpsrvd/cpdavd gestoppt werden.
3. Kompromittierung prüfen: Das Detection-Script ausführen und die Sitzungsverzeichnisse manuell auf IOCs untersuchen.
4. Zugangsdaten rotieren: Alle Root- und WHM-Reseller-Passwörter zurücksetzen, API-Tokens erneuern, SSH-Keys überprüfen und gegebenenfalls neu ausstellen.
5. Kompromittierte Server neu aufsetzen: Bei bestätigter Kompromittierung keine In-Place-Bereinigung versuchen, sondern den Server aus einem sauberen, gepatchten Image neu aufsetzen.
6. Packagist-Abhängigkeiten bereinigen: Dev-main-Versionen der betroffenen dinushchathurya-Pakete entfernen und auf stabile, verifizierte Releases wechseln.
7. GitHub Actions absichern: Workflow-Dateien prüfen, GITHUB_TOKEN-Berechtigungen auf das Minimum reduzieren und für externe Workflows eine Genehmigungspflicht einrichten.
8. Monitoring einrichten: Ausgehenden Netzwerkverkehr von CI/CD-Systemen überwachen und Alerts für Payload-Downloads von rohen IP-Adressen in Workflows setzen.

Einordnung: Der Patch kam spät – und wird oft nicht eingespielt

Diese Schwachstelle hat eine lange Vorgeschichte. Laut Daniel Pearson, CEO von KnownHost, wurde CVE-2026-41940 bereits um den 23. Februar 2026 als Zero-Day (also vor jeder öffentlichen Bekanntgabe) aktiv ausgenutzt – rund 64 Tage, bevor cPanel am 28. April 2026 den Notfall-Patch veröffentlichte.

„Das ist definitiv in freier Wildbahn ausgenutzt worden, und zwar mindestens in den letzten 30 Tagen, wenn nicht länger.“ – Daniel Pearson, CEO von KnownHost

Am 30. April 2026 nahm die US-Behörde CISA die Schwachstelle in ihren Katalog bekannter ausgenutzter Schwachstellen (KEV) auf und setzte US-Bundesbehörden eine Patch-Frist bis zum 3. Mai. Die Shadowserver Foundation meldete zu diesem Zeitpunkt rund 44.000 an Angriffen beteiligte IP-Adressen. Die aktuelle GitHub-Actions-Kampagne beweist: Auch Monate nach dem Patch nutzen Angreifer die Lücke im großen Stil weiter – weil viele Server schlicht nicht aktualisiert werden.

DSGVO: Warum eine Kompromittierung teuer werden kann

Für deutsche KMU hat eine cPanel/WHM-Kompromittierung erhebliche datenschutzrechtliche Konsequenzen. Da bei einer Server-Übernahme typischerweise Kundendaten, Datenbankzugangsdaten und E-Mail-Inhalte betroffen sind, ist von einer Verletzung des Schutzes personenbezogener Daten auszugehen.

Gemäß Art. 33 DSGVO muss ein solcher Vorfall unverzüglich, möglichst binnen 72 Stunden nach Bekanntwerden, der zuständigen Aufsichtsbehörde (in Deutschland die Landesbehörden, etwa BayLDA, LfDI Baden-Württemberg oder die Berliner Beauftragte für Datenschutz) gemeldet werden, sofern ein Risiko für die Rechte und Freiheiten natürlicher Personen besteht. Bei hohem Risiko kann nach Art. 34 DSGVO zusätzlich eine Benachrichtigungspflicht gegenüber den betroffenen Personen greifen.

Wichtig für KMU im Managed Hosting: Ihr Hosting-Provider ist als Auftragsverarbeiter nach Art. 33 Abs. 2 DSGVO verpflichtet, Sie als Verantwortlichen unverzüglich über eine Datenpanne zu informieren. Prüfen Sie, ob Ihr Auftragsverarbeitungsvertrag (AVV) entsprechende Klauseln enthält. Bußgelder für Verstöße gegen die Meldepflichten können bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes betragen – die irische Datenschutzbehörde verhängte 2024 allein wegen verspäteter Meldung 1,2 Millionen Euro. Europaweit wurden 2025 über 167.000 Datenpannen gemeldet, ein Anstieg von 14 % gegenüber dem Vorjahr.

Fazit

Diese Kampagne verbindet zwei ernste Bedrohungen: eine bereits als Zero-Day ausgenutzte, kritische Authentifizierungs-Umgehung in einer Software, die 94 % des Kontrollpanel-Marktes dominiert – und einen Supply-Chain-Angriff, der GitHubs eigene Infrastruktur als kostenloses Angriffsnetzwerk missbraucht. Für deutsche KMU ist das Risiko hoch, denn eine erfolgreiche Übernahme bedeutet Root-Zugriff auf den gesamten Server: alle gehosteten Websites, alle Kundendaten, alle Zugangsdaten.

Die gute Nachricht: Ein Patch existiert seit dem 28. April 2026. Die schlechte: Er wirkt nur, wenn er eingespielt wird. Prüfen Sie deshalb noch heute Ihre cPanel-Version, beschränken Sie die Zugriffs-Ports, führen Sie das Detection-Script aus – und sprechen Sie Ihren Hosting-Provider aktiv an. Wer PHP-Projekte entwickelt, sollte zusätzlich seine Packagist-Abhängigkeiten und GitHub-Workflows kontrollieren. Warten kostet in diesem Fall im Zweifel weit mehr als ein Update.