// Coding 24.07.2026 · 15:33 Uhr 4 Min. Lesezeit

Missbrauch von GitHub Actions zur Durchführung von Angriffen auf cPanel- und WHM-Server

Mindverse News

KI-gestützt erstellt 10 Quellen Arbeitsweise

Missbrauch von GitHub Actions zur Durchführung von Angriffen auf cPanel- und WHM-Server — Symbolbild

Das Wichtigste in Kürze

Angreifer nutzten GitHub Actions, um über kompromittierte Packagist-Repositories cPanel- und WHM-Server zu scannen und Anmeldeinformationen zu stehlen.
Die Attacke umfasste 583 bösartige Workflow-Dateien in zehn Packagist-Paketen, die temporäre GitHub Runner für Scans missbrauchten.
Die Angreifer zielten auf cPanel- und WHM-Schwachstellen ab (CVE-2026-41940), um Cloud-Schlüssel, Zahlungsinformationen und Quellcode-Tokens zu erbeuten.
Die Ausführung der bösartigen Logik erfolgte nicht über die PHP-Pakete selbst, sondern über die GitHub Actions Workflows in den kompromittierten Repositories.
Organisationen sind angehalten, ihre GitHub-Repositories und CI/CD-Pipelines zu sichern, insbesondere durch strenge Zugriffskontrollen und Überwachungsmechanismen.

// Inhalt · 4 Abschnitte

Missbrauch von GitHub Actions zur Erstellung verteilter Scanner
Ziele der Angreifer: cPanel- und WHM-Server
Analyse der Code-Wiederverwendung
Präventive Maßnahmen und Empfehlungen
Quellen

In einer aktuellen Analyse wurde eine breit angelegte Missbrauchskampagne aufgedeckt, bei der GitHub Actions dazu verwendet wurden, Packagist-Repositories in Scanner für cPanel- und WHM-Server umzuwandeln. Diese Kampagne, die von Sicherheitsexperten detailliert beschrieben wurde, verdeutlicht eine sich entwickelnde Bedrohungslandschaft im Bereich der Softwarelieferkette und der Cloud-Infrastruktur.

Missbrauch von GitHub Actions zur Erstellung verteilter Scanner

Der Vorfall begann mit der Kompromittierung von GitHub-Repositories eines PHP- und DevOps-Entwicklers, der unter dem Namen "dinushchathurya" bekannt ist. Angreifer erlangten Zugang zu diesen Repositories, injizierten bösartige Workflow-Dateien in das Verzeichnis .github/workflows/ und pushten diese Änderungen auf Branches, die anschließend von Packagist als Entwicklungs-Releases synchronisiert wurden. Insgesamt waren zehn Packagist-Pakete betroffen, die zusammen 583 bösartige Workflow-Dateien enthielten.

Es ist wichtig zu betonen, dass die PHP-Bibliotheken selbst nicht die Angriffslogik ausführten. Die Analyse zeigte, dass diese Bibliotheken gewöhnlichen PHP-Code enthielten, der statische Referenzdaten und Suchfunktionen umfasste, ohne bösartige Installations-Hooks, Shell-Befehle oder ausgehende Netzwerkaktivitäten. Stattdessen nutzten die Angreifer die übergeordneten GitHub Actions-Konfigurationen jedes Repositories, um Code in der CI/CD-Umgebung von GitHub auszuführen.

Funktionsweise des Angriffs

Jede bösartige Packagist-Entwicklungsversion enthielt zwischen 55 und 62 Workflow-Dateien. Diese Workflows waren so konfiguriert, dass sie bei jedem Push auf einen Branch und über das workflow_dispatch-Ereignis gestartet wurden. GitHub stellte daraufhin einen Ubuntu-Runner bereit – eine temporäre virtuelle Maschine, die üblicherweise für Build- und Testaufgaben genutzt wird. Der Workflow prüfte die Prozessorarchitektur des Runners, lud eine passende Linux-Executable von einem externen Server (43.228.157.68) herunter, vergab Ausführungsberechtigungen und startete diese.

Die Angreifer nutzten die Scanner-Argumente, um gezielt Ports zu adressieren, die typischerweise mit Webdiensten sowie cPanel- und WHM-Administrationsschnittstellen verbunden sind. Dazu gehörten die Ports 80, 443, 8080, 8443, 2082, 2083, 2086 und 2087. Das Ziel war die Ausnutzung der Schwachstelle CVE-2026-41940, die als Authentifizierungs-Bypass-Problem in cPanel und WHM beschrieben wird.

Datenexfiltration und Überwachung

Die heruntergeladene ausführbare Datei führte die Scan- und Exploit-Versuche durch. Die Workflow-Dateien stellten eine Steuerungsebene für die Ausführung, Dateisammlung und Datenübertragung bereit. Ein Hintergrundprozess sendete alle 30 Sekunden einen Status-Update an den Angreifer-Endpunkt /api/github-heartbeat. Diese HTTP-POST-Anfrage enthielt den Repository-Namen und die letzte Zeile des Scanner-Logs, was dem Angreifer eine laufende Überwachung der Aktivitäten innerhalb jedes GitHub Actions-Jobs ermöglichte.

Die Workflows überwachten zudem Ausgabedateien auf neu erfasste Informationen. Dazu gehörten AWS-Anmeldeinformationen, GitHub- und GitLab-Tokens, OpenAI- und Google API-Anmeldedaten, Stripe-Schlüssel, SendGrid- und Mailgun-Anmeldedaten, Datenbankverbindungsdaten, SSH-Material, Git-Remote-Informationen, Umgebungsvariablen und Konfigurationsdateien. Die gesammelten Daten wurden in Chunks an /api/github-results gesendet, wobei Zeilen-Offsets vermerkt wurden, um redundante Übertragungen zu vermeiden.

Ziele der Angreifer: cPanel- und WHM-Server

Die Kampagne konzentrierte sich auf internetzugängliche cPanel- und WHM-Systeme. cPanel ermöglicht einzelnen Hosting-Kunden die Verwaltung von Websites, Datenbanken, E-Mail-Konten und Anwendungseinstellungen. WHM verwaltet die Serverumgebung und kann mehrere cPanel-Konten administrieren. Eine erfolgreiche WHM-Kompromittierung könnte mehrere Kundenumgebungen von einem Server aus gefährden, während eine cPanel-Kompromittierung die Website-Dateien, Datenbanken, Postfächer, Bereitstellungsanmeldeinformationen und Anwendungsgeheimnisse eines einzelnen Kunden preisgeben könnte. Das operative Risiko erstreckt sich über die Hosting-Umgebung hinaus, wenn Angreifer Quellcode-Tokens oder Cloud-Zugriffsschlüssel erlangen, die Wege zu Repositories, Cloud-Workloads, Zahlungsplattformen und E-Mail-Zustelldiensten eröffnen können.

Analyse der Code-Wiederverwendung

Sicherheitsexperten entdeckten einen DNS-Callback-Identifier (f5b0b742-240a-4811-8a5b-b0ba6060685d.dnshook.site) in 14 wiederhergestellten Workflows. Eine GitHub Code Search-Abfrage nach diesem Identifier ergab etwa 6.100 übereinstimmende Workflow-Dateien. Suchanfragen nach der Command-and-Control-Adresse, dem Scanner-Befehl, Dateinamen für Anmeldeinformationen, dem Heartbeat-Endpunkt und dem Exfiltrationscode lieferten etwa 15.000 bis 16.000 übereinstimmende Dateien. Diese Zahlen deuten auf eine breitere Nutzung des bösartigen Codes hin, auch wenn sie nicht direkt die Anzahl der kompromittierten Repositories oder Konten belegen.

Präventive Maßnahmen und Empfehlungen

Um sich vor derartigen Angriffen zu schützen, sind umfassende Sicherheitsmaßnahmen erforderlich:

Repository-Zugriffskontrolle: Repository-Besitzer sollten eine Überprüfung und Genehmigung für Änderungen unter .github/workflows/ vorschreiben und Warnmeldungen für Workflows einrichten, die ausführbare Dateien von rohen IP-Adressen herunterladen, curl oder wget vor dem Ausführen unbekannter Binärdateien aufrufen oder ausgehende POST-Anfragen mit Umgebungsdaten senden.
Minimale Berechtigungen: Die Berechtigungen für GITHUB_TOKEN sollten auf das absolute Minimum beschränkt werden, das jeder Workflow benötigt.
Überprüfung von Organisationseinstellungen: Organisationen sollten die Kontrollen überprüfen, die regeln, welche Actions ausgeführt werden dürfen.
Self-Hosted Runner: Bei selbst gehosteten Runnern ist eine noch strengere Behandlung erforderlich, da sie Dateien, Anmeldeinformationen und Netzwerkzugriff nach Beendigung eines Jobs beibehalten können. Egress-Überwachung und Workflow-Überprüfung sind auch für GitHub-gehostete Runner unerlässlich, da Angreifer diese zum Scannen externer Systeme nutzen können.
Packagist-Nutzung: Packagist-Benutzer sollten ungeprüfte Entwicklungsversionen meiden, Composer-Lockfile-Commit-Referenzen überprüfen und Abhängigkeiten an bekannte, funktionierende Commits oder stabile Releases anheften.
cPanel- und WHM-Sicherheit: cPanel- und WHM-Betreiber sollten die Patch-Anweisungen des Anbieters für CVE-2026-41940 anwenden, das IOC-Erkennungsskript von cPanel ausführen, serverseitige Geheimnisse nach einem vermuteten Vorfall rotieren und nicht autorisierte Sitzungen überprüfen.

Die Kompromittierung des GitHub-Kontos, das mit "dinushchathurya" in Verbindung gebracht wird, führte zu dessen Sperrung. Diese Maßnahme eliminierte eine Quelle für Runner-Jobs, beseitigt jedoch nicht die in andere Repositories kopierten Workflows oder die bereits von nachgelagerten Systemen gesammelten Anmeldeinformationen. Die Vorfälle unterstreichen die Notwendigkeit einer kontinuierlichen Wachsamkeit und robuster Sicherheitsstrategien in der gesamten Softwarelieferkette.