Lieferkettenangriff über GitHub Actions : GhostAction stiehlt Cloud-Zugangsdaten über GitHub

Ein bekannter Absender und ein unverdächtiger Dateiname können Schadcode wie einen normalen Bestandteil eines Entwicklungsprojekts aussehen lassen. Bei GhostAction übernehmen Angreifer Entwicklerkonten und nutzen deren Schreibrechte, um schädliche GitHub-Actions-Workflows in Projekte einzuschleusen. Diese Workflows sind automatisierte Abläufe, die beispielsweise Software bauen oder testen. Sobald der eingeschleuste Ablauf startet, läuft der Schadcode in der technischen Umgebung des Projekts. Dort kann er auf den bereitgestellten Quellcode und auf die Zugangsdaten zugreifen, die diesem Ablauf zur Verfügung stehen (siehe auch Kettenreaktionen: Supply-Chain-Attacken – Bedrohung und Abwehr).

Damit richtet sich der Angriff gegen eine zentrale Vertrauensgrenze der Softwareentwicklung: Wer automatisierte Arbeitsabläufe verändern darf, kann unter Umständen auch bestimmen, welche Programme auf einem Build-System laufen und wohin vertrauliche Informationen übertragen werden.

Von einzelnen Entwicklerkonten zur breit angelegten Kampagne

Die von StepSecurity dokumentierte Angriffswelle traf unter anderem die Konten zweier bekannter Open-Source-Entwickler. Zunächst nutzten die Angreifer das Konto von Takashi Kitao, dem Entwickler der Spiele-Engine pyxel, die auf GitHub rund 18.400 Sterne erhalten hat. Ab 13:20 Uhr UTC schleusten sie darüber einen schädlichen automatisierten Ablauf in 27 Softwareprojekte ein. Rund acht Stunden später nutzten sie das Konto von Henry Wu, dem ursprünglichen Entwickler von Ubers athenadriver. Über dieses Konto erreichten sie innerhalb von nur 16 Minuten weitere 318 Projekte.

Diese beiden Fälle bilden nur einen Ausschnitt. Socket berichtet mit Stand vom 9. Oktober 2026 von mehr als 500 GitHub-Konten, über die seit dem 7. Oktober schädliche Workflows in Zehntausende Repositories gelangten. Die Zahl beschreibt die Verbreitung der Workflow-Dateien; sie belegt nicht automatisch, dass in jedem Repository Zugangsdaten gestohlen wurden.

GhostAction ist bereits seit September 2025 bekannt. Die damalige Untersuchung von StepSecurity erfasste 817 betroffene Repositories von 327 GitHub-Nutzern sowie 3.325 abgeflossene Secrets, darunter Veröffentlichungstoken für den Python Package Index (PyPI), npm und Docker Hub. Ein Secret kann beispielsweise ein Zugriffstoken, ein privater Schlüssel oder ein Passwort sein.

Die Angriffskette beginnt mit gestohlenen GitHub-Zugangsdaten

Als wahrscheinlichen Einstieg nennen die Analysen einen entwendeten persönlichen Zugriffstoken, (Personal Access Token, kurz PAT). Solche Token ermöglichen abhängig von ihren Berechtigungen authentifizierte Zugriffe auf GitHub. Die Herkunft aus Infostealer-Protokollen oder Sammlungen gestohlener Zugangsdaten ist eine plausible Erklärung, jedoch kein abschließend belegter Erstzugang für sämtliche Fälle.

Die Angriffskette umfasst vier Schritte:

• GitHub-Zugangsdaten eines Maintainers beschaffen: Vermutlich verwenden die Angreifer einen geleakten PAT aus Infostealer-Protokollen oder Zugangsdatenbeständen.
• Vorhandene Workflows auskundschaften: Die Workflow-Dateien des Repositories werden nach Verweisen auf Secrets durchsucht.
• Einen getarnten Sicherheitsaudit einschleusen: Unter der Identität des kompromittierten Kontos gelangt der präparierte Workflow in den Standardbranch.
• Daten sammeln und übertragen: Die eingebettete Nutzlast extrahiert vertrauliche Informationen und sendet sie mit curl an einen vom Angreifer kontrollierten Endpunkt.

Die Auskundschaftung ist technisch relevant: Ein Verweis wie ${{ secrets.DEPLOY_KEY }} verrät den Namen eines Secrets, ohne dessen Wert offenzulegen. Ein Angreifer mit den erforderlichen Rechten kann diesen Namen anschließend im eingeschleusten Workflow verwenden. Bei der Ausführung stellt GitHub den Wert bereit, sofern die Zugriffsregeln des jeweiligen Kontexts dies erlauben.

Das ist keine pauschale Lesemöglichkeit für alle gespeicherten Secrets. Organisationsrichtlinien, geschützte Umgebungen und Freigaben können den Zugriff einschränken. Ein bösartiger Workflow missbraucht jedoch genau die Berechtigungen, die ihm tatsächlich eingeräumt werden.

Warum der nächste reguläre Push den Diebstahl auslösen kann

Die beobachteten Dateien heißen security-audit.yml oder github_actions_security.yml. Ihre Anzeigenamen „Security Audit“ beziehungsweise „GitHub Actions Security“ tarnen den Zweck als Sicherheitsmaßnahme.

Die aktuelle Variante reagiert auf workflow_dispatch, also eine manuelle Auslösung, und auf ein ungefiltertes push-Ereignis. Damit können sowohl Branch- als auch Tag-Pushes einen Lauf anstoßen. Die Gefahr bleibt nach dem Einschleusen bestehen: Auch eine spätere, legitime Änderung kann die Datensammlung auslösen, wenn der Workflow auf dem betreffenden Git-Stand vorhanden und ausführbar ist.

Beim Checkout setzt der Workflow fetch-depth: 0. Statt einer verkürzten Versionshistorie erhält der Job dadurch die vollständige Git-Historie der ausgecheckten Quelle. Der als „Audit“ bezeichnete Schritt erledigt vier Aufgaben:

• Bekannte Secrets hinzufügen: Die während der Auskundschaftung ermittelten, namentlich referenzierten Repository-Secrets werden in die Datensammlung aufgenommen.
• Den aktuellen Arbeitsbaum durchsuchen: 13 Erkennungsmuster suchen nach Zugangsdaten für Amazon Web Services (AWS), KI-Dienste, Quellcodeplattformen sowie Cloud- und Software-as-a-Service-Angebote (SaaS).
• Die gesamte Git-Historie prüfen: Dieselben 13 Muster erfassen auch Zugangsdaten, die früher eingecheckt und später aus aktuellen Dateien entfernt wurden.
• AWS-Zugangsdaten zusammenführen: Gefundene Access Key IDs werden den zugehörigen Secret Access Keys zugeordnet.

Welche 13 Muster konkret verwendet werden, ist derzeit noch nicht vollständig geklärt. Bekannt sind unter anderem Schlüssel für Anthropic, OpenAI und OpenRouter sowie GitHub- und GitLab-Token.

Gelöschte Schlüssel bleiben in der Versionshistorie auffindbar

Das Entfernen eines Schlüssels aus der aktuellen Datei macht frühere Commits nicht ungeschehen. Solange diese über die Git-Historie erreichbar bleiben, lässt sich der ursprüngliche Inhalt wiederherstellen. GhostAction nutzt deshalb zwei Datenquellen: ausdrücklich bereitgestellte Workflow-Secrets und Zugangsdaten, die versehentlich im Quellcode gespeichert wurden.

Die Zuordnung von AWS-Schlüsselpaaren erhöht den praktischen Wert der Beute. Eine Access Key ID allein genügt nicht zur Authentifizierung; zusammen mit dem passenden Secret Access Key kann sie jedoch API-Aufrufe ermöglichen. Welche Ressourcen erreichbar sind, hängt von den Berechtigungen der zugehörigen Identität ab.

Die Übertragung erfolgt an die fest eingetragene Adresse 193.32.204[.]199 über das unverschlüsselte http-Protokoll. Neben dem Diebstahl durch den Empfänger entsteht damit das Risiko, dass Daten auf dem Übertragungsweg mitgelesen werden. Eine Maskierung vertraulicher Werte in Workflow-Protokollen verhindert diesen Abfluss nicht: Sie schützt die Darstellung im Log, nicht die Verwendung eines Secrets durch ausgeführten Code.

Betroffene Repositories sind nicht gleich erfolgreiche Diebstähle

Eine Analyse von GitGuardian erfasste zwischen dem 31. August und dem 30. September 2026 insgesamt 772 öffentliche Repositories von 373 GitHub-Nutzern und Organisationen. Die eingeschleusten Workflows zielten dort auf 2.577 Secrets. Diese Geheimnisse lassen sich in folgende Kategorien gliedern:

• Private Schlüssel für Secure Shell (SSH)
• Azure-Zugangsdaten
• Zugangsdaten für Docker Hub und die GitHub Container Registry (GHCR)
• Datenbankzugangsdaten
• AWS-Zugriffsschlüssel
• Zugangsdaten für das File Transfer Protocol (FTP)
• Google-Cloud- und Firebase-Zugangsdaten
• GitHub-Token
• Bot-Token für Telegram, Slack und Discord
• Schlüssel für Cloudflare, npm, PyPI und KI-Anbieter

Diese Kategorien zeigen, welche Daten die Angreifer stehlen wollten. Sie belegen jedoch nicht, welche Daten tatsächlich abgeflossen sind. GitGuardian unterscheidet deshalb drei Schritte: Wurde eine schädliche Datei eingeschleust? Wurde der darin enthaltene automatisierte Ablauf gestartet? Und wurden tatsächlich Daten an die Angreifer übertragen? Bei einem großen Teil der im September untersuchten Abläufe verhinderten erforderliche Freigaben die Ausführung.

Die verschiedenen Fallzahlen dürfen daher weder addiert noch als einheitliche Opferzahl behandelt werden. Sie beziehen sich auf unterschiedliche Zeiträume und Messgrößen: kompromittierte Konten, veränderte Repositories, anvisierte Secrets und tatsächlich abgeflossene Werte.

Forks verlängern die Lebensdauer des Angriffs

Forks übernehmen beim Erstellen oder Synchronisieren Quellcode aus einem anderen Repository. Dazu können auch Dateien unter .github/workflows/ gehören. Wird der schädliche Workflow mitübernommen, kann die Kopie einen eigenen Angriffskontext bilden.

Socket hebt hervor: „Die 279 Forks im Namensraum henrywoo enthalten jeweils die Workflow-Datei.“ Sind Actions aktiviert und die Ausführungsbedingungen erfüllt, können spätere Pushes die Datensammlung erneut starten.

Besondere Aufmerksamkeit verdienen private Forks und nachgelagerte Spiegelungen. Dort können zusätzliche Zugangsdaten oder vertrauliche Konfigurationen vorhanden sein. Zugleich liefert die Nutzlast nach Angaben von Socket bei jedem Lauf eine Repository-Kennung zurück, auch wenn keine Schlüssel gefunden wurden. Der Betreiber erhält so eine Übersicht erreichbarer Ausführungskontexte.

Ein kompromittiertes Konto kann mehrere Angreifer bedienen

Im Repository kuafuai/DevOpsGPT wurde außerdem eine Manipulation vom 30. August 2026 beobachtet, die den Kryptowährungsminer XMRig in das Docker-Image des Projekts integrierte. Das zeigt, dass gestohlene Entwicklerzugänge nicht ausschließlich zum Abgreifen weiterer Schlüssel eingesetzt werden.

Die Zuordnung dieses Miners zu GhostAction bleibt allerdings unsicher. GitGuardian erklärt: „Wir sind nicht überzeugt.“ Die Analyse beschreibt abweichende Merkmale und hält es für möglich, dass mehrere unabhängige Akteure dasselbe kompromittierte Konto nutzten.

Nach aktuellem Kenntnisstand waren keine bösartigen Paketveröffentlichungen mithilfe der entwendeten Veröffentlichungstoken bekannt. Das begrenzt den belegten Schaden, beseitigt aber nicht das Risiko weiterer Manipulationen.

Bereinigung muss den Erstzugang und die Folgeschäden erfassen

Die im Ausgangsbericht empfohlenen Maßnahmen greifen ineinander:

• Repositories prüfen: Seit dem 31. August 2026 nach security-audit.yml und github_actions_security.yml suchen und bei einem Fund von einer möglichen Kompromittierung ausgehen.
• Den kompromittierten GitHub-Zugang widerrufen: Das Token oder die andere Zugangsmöglichkeit sperren, die das Einschleusen erlaubt hat.
• Gefährdete Zugangsdaten austauschen:Secrets und Schlüssel rotieren, die dem Workflow zugänglich waren oder im Arbeitsbaum beziehungsweise in der Historie standen.
• Schädliche Workflows aus allen Branches entfernen: Die Bereinigung darf sich nicht auf den Standardbranch beschränken.
• Forks kontrollieren: Kopien betroffener Repositories und nachgelagerte Spiegelungen auf übernommene Workflows prüfen.

Nur nach zwei bekannten Dateinamen zu suchen, reicht nicht aus. GitGuardian hat auch eine Variante mit dem Namen security-check.yml dokumentiert. Deshalb sollten Verantwortliche zusätzlich prüfen, ob automatisierte Abläufe unerwartet verändert wurden, Daten an unbekannte Ziele übertragen werden oder neue Verweise auf gespeicherte Zugangsdaten auftauchen.

Für einen dauerhaften Schutz müssen Änderungen an diesen Abläufen verbindlich geprüft werden. Konten und Zugriffsschlüssel sollten nur die Rechte erhalten, die sie tatsächlich benötigen. Abläufe mit Zugriff auf sensible Daten oder Systeme sollten eine ausdrückliche Freigabe erfordern (siehe auch: DevSecOps (1)). Die Suche nach offengelegten Zugangsdaten muss auch ältere Versionen des Quellcodes einschließen. Auf den Systemen, die diese Abläufe ausführen, können Netzwerkkontrollen Verbindungen zu unerwarteten Zielen blockieren.

GhostAction zeigt: Wer Dateien in einem Softwareprojekt verändern kann, erhält unter Umständen auch Zugang zu Cloud-Diensten, Paketverzeichnissen und Produktionssystemen. Zur Bereinigung gehört deshalb, den kompromittierten GitHub-Zugang zu sperren, gefährdete Zugangsdaten zu ersetzen und alle noch ausführbaren Kopien des schädlichen Ablaufs zu entfernen.