GhostAction-Supply-Chain-Angriff kapert über 340 GitHub-Repositories über zwei Maintainer-Accounts

Eine erneute Welle des GhostAction-Supply-Chain-Angriffs kompromittierte am 8. Oktober 2026 zwei bekannte Open-Source-Maintainer-Accounts und nutzte deren Push-Zugriff, um innerhalb von Minuten einen credential-stehlenden GitHub Actions Workflow in mehr als 340 Repositories einzupflanzen – das belegt eine von StepSecurity veröffentlichte Untersuchung.

Der erste Account gehörte dem Entwickler der pyxel-Game-Engine, einem Projekt mit rund 18.400 GitHub-Stars. Über ihn wurde der bösartige Workflow zwischen 13:20 und 13:44 UTC in 27 Repositories gepusht. Acht Stunden später pushte ein zweiter kompromittierter Account – der des ursprünglichen Autors von Ubers Open-Source-Bibliothek athenadriver – denselben Workflow in einem einzigen 16-Minuten-Fenster in 318 Repositories, darunter 39 Quellprojekte und 279 Forks. Der Zugriff reichte bis in Ubers eigene GitHub-Organisation, bevor das Unternehmen eingreifen konnte.

GitHub Actions Workflows sind zu einem bevorzugten Ziel für Supply-Chain-Angreifer geworden, weil ein einziger kompromittierter Maintainer-Account unbemerkt bösartige Automatisierung in jedes Repository einschleusen kann, auf das dieser Account Schreibzugriff hat – und diese Automatisierung läuft dann mit dem Vertrauen und den Credentials, die bereits für das jeweilige Projekt konfiguriert sind. Die ursprüngliche GhostAction-Kampagne, die im September 2025 identifiziert wurde, stahl mehr als 3.300 Secrets aus 817 Repositories von 327 Entwicklern. Diese zweite Welle wiederholte dasselbe Vorgehen in größerem Maßstab und gegen prominentere Ziele.

Die eingeschleusten Dateien – benannt security-audit.yml und eine ältere Variante namens github_actions_security.yml – waren als routinemäßige Security-Scanning-Jobs getarnt. Nach der Ausführung durchsuchten sie sowohl den Working Tree als auch die vollständige Git-Historie, einschließlich gelöschter Dateien, nach 13 Kategorien von Credentials: AWS Access Keys und Session Tokens, API-Keys von Anthropic, OpenAI und OpenRouter, GitHub- und GitLab-Tokens, Google- und Firebase-Keys, Slack-Bot-Tokens sowie SendGrid-Credentials. Außerdem wurden spezifisch benannte Secrets ausgelesen, die bereits in den Workflows der jeweiligen Repositories konfiguriert waren – etwa PyPI- und Cargo-Publishing-Tokens. Alles Gefundene wurde im Klartext an einen fest codierten Command-and-Control-Server übermittelt.

Zum 9. Oktober hatte StepSecurity 378 Repositories identifiziert, auf deren Default Branch der aktive bösartige Workflow noch vorhanden war, mit bestätigten Belegen, dass benannte Secrets aus mindestens 88 davon exfiltriert worden waren. Zum Zeitpunkt der Veröffentlichung der Untersuchung waren noch keine bösartigen Package-Releases aufgetaucht, die auf gestohlene Publishing-Credentials zurückzuführen gewesen wären. Das Unternehmen warnte jedoch, dass jedes Repository, das einen abgeschlossenen Lauf des Workflows aufweist, als bestätigter Breach behandelt werden sollte.

Der Vorfall ist eine Erinnerung daran, dass das Vertrauen in Open Source über individuelle Maintainer-Accounts läuft und nicht über Organisationen: Ubers eigenes Repository war betroffen – nicht weil Uber direkt ins Visier genommen wurde, sondern weil die kompromittierten Credentials eines externen Contributors zufällig Zugriff darauf hatten. StepSecurity fordert alle Maintainer betroffener Projekte auf, sämtliche Credentials zu rotieren, die jemals in irgendeinen Branch committed wurden – da der History-Mining-Schritt des Angriffs auch längst gelöschte Secrets ausliest –, die kompromittierten Sessions zu widerrufen, den Workflow aus jedem Branch und Fork zu entfernen und vor jeder Änderung am .github/workflows-Verzeichnis eines Repositories einen Pull-Request-Review zu verlangen.