GhostAction GitHub Actions Angriff stiehlt Secrets

Der GhostAction GitHub Actions Angriff ist zurück, und seine Nutzlast liest jetzt die gesamte Git-Historie eines Repositorys. Forscher berichten, dass Angreifer am 8. Oktober die Konten zweier bekannter Maintainer übernahmen und innerhalb von Minuten einen Workflow namens „Security Audit“ in 345 Repositories schoben. Wer nur seine aktuellen Actions-Secrets rotiert, schließt die Lücke nicht mehr, denn der Workflow sammelt auch Zugangsdaten ein, die einmal committet und vor Jahren wieder gelöscht wurden.

Was ist passiert

StepSecurity beschreibt den GhostAction GitHub Actions Angriff vom 8. Oktober als zwei automatisierte Durchläufe. Über das Konto von Takashi Kitao, Autor der Game-Engine pyxel, schob der Angreifer den Workflow in 27 Repositories. Acht Stunden später diente das Konto von Henry Wu, ursprünglicher Autor von Ubers athenadriver, dazu, ihn in 16 Minuten in 318 Repositories zu pushen, darunter uber/athenadriver, wo er Schreibrechte behalten hatte. Die Commits gingen ohne Pull Request direkt auf den Default-Branch, unter dem Namen der Inhaber. Als wahrscheinlicher Einstieg gilt ein geleaktes Personal Access Token aus Infostealer-Logs oder Credential-Dumps; das ist die Schlussfolgerung der Forscher, kein bestätigter Befund.

Der Workflow, benannt „Security Audit“ oder „Github Actions Security“, läuft bei jedem Push auf jeden Branch und bei manuellem Start. Er sendet die benannten Secrets des Repositorys per unverschlüsseltem HTTP an eine fest hinterlegte IP-Adresse (193.32.204[.]199). Neu ist, was er mit einem vollständigen Checkout tut: Er durchsucht den Arbeitsbaum und, über git log mit der Option –all, jeden Commit auf jedem Branch nach 13 Zugangsdatenmustern, darunter AWS-Schlüssel, GitHub- und GitLab-Tokens sowie API-Schlüssel von Anthropic, OpenAI und OpenRouter. StepSecurity bestätigte anhand des Run-Logs, dass die Exfiltration aus uber/athenadriver gelang.

Der Umfang ist noch unklar. Socket zählt seit dem 7. Oktober mehr als 500 GitHub-Konten und zehntausende Repositories. GitGuardian zählt für den Zeitraum 31. August bis 30. September 772 öffentliche Repositories von 373 Nutzern und Organisationen mit 2.577 anvisierten Secrets. Die Code-Suche von StepSecurity fand am 9. Oktober 378 Repositories mit dem Workflow im Default-Branch. Nach den von uns gelesenen Berichten wurden mit den gestohlenen Publishing-Zugangsdaten bisher keine schädlichen Paketversionen veröffentlicht; StepSecurity betont, dass das kein Beleg dafür ist, dass die Zugangsdaten sicher sind.

Warum das wichtig ist

Die Bereinigung hat sich geändert. Ein Secret, das 2019 committet und am nächsten Tag gelöscht wurde, steckt weiter in der Historie, und der Workflow nimmt es mit. Der Angreifer arbeitet zudem unter legitimen Identitäten, sodass Audit-Logs unauffällig wirken, solange niemand den Workflow-Inhalt liest. Eine Kontrolle stoppte die Exfiltration in einem von StepSecurity analysierten Repository: die Pflicht, Workflow-Läufe freizugeben.

Für DACH kennen wir keine deutschen Opfer, und die Berichte nennen überwiegend Open-Source-Maintainer. Einschätzung: Jedes mittelständische Unternehmen, dessen Entwickler Zugriffstokens auf Laptops halten, Repositories spiegeln oder Pakete veröffentlichen, ist derselben Kette ausgesetzt. Einen ähnlichen identitätsbasierten Weg in die Build-Kette haben wir in unserem Beitrag zum Keyv-npm-Wurm und im AsyncAPI-Beitrag behandelt.

Was Sie jetzt tun sollten

1. Durchsuchen Sie Ihre GitHub-Organisation und persönlichen Repositories nach den Workflow-Namen „Security Audit“ und „Github Actions Security“, den Dateinamen security-audit.yml und github_actions_security.yml sowie der Adresse 193.32.204[.]199 in Workflow-Dateien. StepSecurity zufolge ist jeder Treffer seit dem 31. August 2026 als bestätigte Kompromittierung zu behandeln.
2. Bei einem Treffer rotieren Sie jede Zugangsinformation, die je in einen Branch committet wurde, nicht nur die konfigurierten Actions-Secrets: Cloud-Schlüssel, KI-Provider-Schlüssel, Registry- und Paket-Tokens, GitHub- und GitLab-Tokens.
3. Widerrufen Sie die GitHub-Zugangsdaten, die den Push ermöglichten, und löschen Sie den Workflow aus allen Branches, nicht nur aus dem Default-Branch. Prüfen Sie auch Forks.
4. Stoppen Sie Releases, bis das Repository sauber ist, und prüfen Sie jüngste Paket- und Image-Veröffentlichungen, falls Publishing-Tokens vorhanden waren.
5. Aktivieren Sie die Freigabe für Workflow-Läufe, schützen Sie das Workflow-Verzeichnis per Branch Protection mit Pflicht-Review und beschränken Sie ausgehenden Verkehr der Runner auf eine Allowlist.

DIESEC Einschätzung

Der Schwachpunkt ist, wer auf einen Default-Branch pushen darf und wo dessen Tokens liegen, nicht der Code von GitHub. Behandeln Sie das Personal Access Token eines Entwicklers wie Produktivzugangsdaten, mit derselben Ablaufzeit und Überwachung.

Nicht sicher, ob ein solcher Workflow in Ihren Repositories gelaufen ist? Kontaktieren Sie DIESEC für eine schnelle Prüfung Ihrer CI/CD-Konfiguration und eine Analyse der Zugangsdaten-Exposition über Ihre Repository-Historie.

Quellen: StepSecurity | The Hacker News | GitGuardian | Socket
Veröffentlicht: 2026-10-13 | Kategorie: Tägliche News | ~4 Min. Lesezeit