Supply-Chain-Angriff: GitHub-Runner werden zur Botnet-Infrastruktur

583 schädliche Workflow-Dateien

Der Kern des Angriffs lag nicht im PHP-Code selbst; die PHP-Bibliotheken blieben gutartig und enthielten keine Installations-Hooks oder schädliche Netzwerkaktivität . Stattdessen injizierten die Angreifer 583 schädliche GitHub Actions-Workflow-Dateien (.github/workflows/*.yml) in die Quell-Repositories des Entwicklers. Jede betroffene Paketversion enthielt zwischen 55 und 62 dieser Workflow-Dateien . GitHub Actions-Workflows sind YAML-Dateien, die automatisierte Aufgaben wie Tests oder Bereitstellungen definieren. Die Angreifer zweckentfremdeten diese legitime Automatisierungsinfrastruktur.

Der schädliche Mechanismus

Sobald ein Fork oder eine Kopie des kompromittierten Repositorys einen Workflow auslöste (z. B. durch ein push-Ereignis), wies die schädliche .yml-Datei den von GitHub gehosteten Ubuntu-Runner an : (1) die CPU-Architektur des Runners zu erkennen; (2) ein Scan- und Exploit-Payload von einem Command-and-Control-Server (C2) unter der IP-Adresse 43[.]228[.]157[.]68 herunterzuladen; (3) das Internet nach Systemen mit cPanel- und WHM-Diensten zu durchsuchen; (4) die identifizierten Systeme automatisch mit der unten beschriebenen Schwachstelle auszunutzen; (5) die gestohlenen Daten an den C2-Server zu exfiltrieren.

Dies verwandelte jeden ausgelösten Workflow effektiv in einen Scan- und Exploit-Knoten, der GitHub‘s kostenlose Infrastruktur als verteilte Plattform für den Angriff nutzte .

Die Schwachstelle: CVE-2026-41940

Das Ziel der Kampagne war CVE-2026-41940, eine kritische Sicherheitslücke in cPanel und WebHost Manager (WHM) .

• Typ: Pre-Authentication-Authentifizierungsumgehung (Authentication Bypass) .
• Schweregrad: CVSS 9.8 (Kritisch) .
• Ursache: Eine CRLF-Injection (Carriage Return Line Feed) im cpsrvd Basic-Authentication-Handler . Ein nicht authentifizierter Angreifer konnte einen manipulierten Authorization-Header mit rohen Zeilenumbrüchen senden. Dadurch war es möglich, beliebige Eigenschaften in eine Sitzungsdatei zu injizieren, wie user=root und hasroot=1, was effektiv Root-Level-Administratorzugriff auf das WHM-Interface ohne gültiges Passwort gewährte .
• Patch-Datum: cPanel veröffentlichte ein Sicherheitsupdate am 28. April 2026 . Das bedeutet, Angreifer hatten mehrere Monate vor Kampagnenbeginn Zeit, den Patch zu analysieren.

Was gestohlen wurde

Sobald der Exploit auf einem kompromittierten cPanel/WHM-Server erfolgreich war, war das Post-Exploitation-Payload darauf ausgelegt, eine breite Palette von Zugangsdaten und Geheimnissen zu sammeln. Zu den primären Zielen gehörten :

• Cloud-Zugangsdaten: Amazon Web Services (AWS)-Keys.
• Quellcode-Verwaltungstokens: GitHub-Tokens, GitLab-Tokens.
• API-Keys: OpenAI-, Google-API-Keys.
• Zahlungsabwicklung: Stripe-Keys.
• E-Mail-Dienst-Zugangsdaten: (z. B. Mailgun, SendGrid).
• Infrastruktur: SSH-Private-Keys, Datenbank-Zugangsdaten.
• Konfigurationsdaten: Git-Remote-Konfigurationen.

Der Diebstahl einer so breiten Palette von Zugangsdaten deutet auf einen datenagnostischen, opportunistischen Zugriff auf alle auf dem kompromittierten Server vorhandenen wertvollen Zugangstokens hin .

Ausmaß der Kampagne: Tausende weitere Repositories kompromittiert

Die 583 Workflow-Dateien in den 10 Packagist-Paketen waren nur die erste Entdeckung. Durch die Analyse von Angreifer-Indikatoren wie einer gemeinsam genutzten DNSHook-Callback-Domain und Code-Wiederverwendungsmustern deckten Forscher eine viel größere Operation auf :

• ~6.100 Workflow-Dateien waren direkt mit derselben anfänglichen Angreifer-Infrastruktur verbunden .
• ~15.000 bis 16.000 Workflow-Dateien auf GitHub wiesen verwandte Muster der Kampagne auf .

Diese massive Diskrepanz deutet stark darauf hin, dass die Angreifer viele weitere Entwicklerkonten und Repositories über das einzelne dinushchathurya-Konto hinaus kompromittiert haben . Die Kampagne war kein Single-Point-of-Failure, sondern eine koordinierte Multi-Account-Operation. The Hacker News berichtete im Mai 2026 über einen separaten, früheren Packagist-Supply-Chain-Angriff, der 8 Pakete mit verwandten schädlichen Elementen kompromittierte , was die Verwundbarkeit des Ökosystems weiter unterstreicht.

Anhaltendes Risiko: Warum die Kampagne wahrscheinlich noch aktiv ist

Die Kampagne stellt eine anhaltende Bedrohung dar, da die Infrastruktur der Angreifer nicht vollständig neutralisiert ist. Die Kampagne kann durch fortgesetzt werden:

• Forks und Spiegelungen: Schädliche Workflow-Dateien können in geforkten oder gespiegelten Kopien der kompromittierten Repositories verbleiben.
• Zwischengespeicherte Snapshots: GitHub‘s eigene Caches können die schädlichen Workflow-Versionen enthalten.
• Gestohlene Zugangsdaten: Die bereits exfiltrierten Zugangsdaten bleiben im Besitz der Angreifer und können für Laterale Bewegung oder zukünftige Angriffe genutzt werden.
• Überlebende C2-Infrastruktur: Der C2-Server (43[.]228[.]157[.]68) könnte noch betriebsbereit sein und aktiv Daten empfangen .

Während das ursprüngliche Entwicklerkonto auf Packagist gesperrt wurde, bedeutet das schiere Ausmaß der übereinstimmenden Workflow-Dateien (bis zu ~16.000), dass die Operation eine große Angriffsfläche hat, die schwer vollständig zu beseitigen ist .

Erforderliche Abwehrmaßnahmen

Basierend auf der veröffentlichten Analyse sollten Organisationen und Entwickler sofort die folgenden Maßnahmen ergreifen :

1. cPanel/WHM sofort patchen: CVE-2026-41940 wurde am 28. April 2026 gepatcht. Jede nicht aktualisierte cPanel- oder WHM-Installation (Versionen nach 11.40) ist für nicht authentifizierte entfernte Angreifer trivial ausnutzbar. Dies ist der mit Abstand wichtigste Schritt.
2. Alle GitHub Actions-Workflows prüfen: Überprüfen Sie jede Workflow-YAML-Datei in Ihren Repositories, insbesondere solche, die:
   • Externe Binärdateien herunterladen und ausführen.
   • Ausgehende Netzwerkverbindungen herstellen.
   • Bei push- oder workflow_dispatch-Triggern ohne manuelle Überprüfung ausgeführt werden.
   • In Entwicklungs- oder Feature-Branches vorhanden sind, die möglicherweise automatisch von einem Paketmanager synchronisiert werden.
3. Alle offengelegten Zugangsdaten rotieren: Gehen Sie davon aus, dass alle auf einem kompromittierten cPanel/WHM-Server vorhandenen Zugangsdaten gestohlen wurden. Dies umfasst unter anderem:
   • Cloud-Provider-Keys (AWS, GCP, Azure).
   • API-Tokens (OpenAI, Google, Stripe).
   • SSH-Keys und Datenbank-Passwörter.
   • Quellcode-Verwaltungstokens (GitHub, GitLab).
4. Auf bekannte Indikatoren einer Kompromittierung (IOCs) prüfen: Durchsuchen Sie Ihre Protokolle nach Netzwerkverbindungen zur C2-IP-Adresse des Angreifers (43[.]228[.]157[.]68) und der bekannten DNSHook-Callback-Domain .
5. Repositories und Paketverwaltung härten:
   • Aktivieren Sie Branch-Protection-Regeln für alle Entwicklungs-Branches.
   • Fordern Sie signierte Commits.
   • Vermeiden Sie die automatische Synchronisierung von Paketregistern (wie Packagist) direkt aus Repository-Branches ohne einen Überprüfungsschritt .
6. Packagist-Entwicklungsversionen überprüfen: Untersuchen Sie bei der Prüfung von Abhängigkeiten speziell Entwicklungsversionen (dev-master, dev-main) auf unerwartete .github/workflows/-Dateien, da der PHP-Code selbst sauber sein kann, während der Angriff vollständig in der CI/CD-Konfiguration lebt .