Das Wichtigste in Kürze
Eine neue GhostAction-Welle macht aus einem kompromittierten Maintainer-Konto ein Werkzeug zum massenhaften Abgreifen von Secrets. Der Angreifer pusht eine Workflow-Datei namens security-audit.yml (oder ähnlich) in jedes Repository, auf das das Konto Schreibzugriff hat. Läuft sie, schickt sie die Actions-Secrets des Repositorys und alle Cloud-, KI- und SaaS-Keys, die irgendwo in der Git-Historie liegen, per unverschlüsseltem HTTP an eine fest eingetragene IP-Adresse.
Für jedes Team, das Builds und Releases über GitHub Actions fährt, ist die Lehre einfach: Ein Secret, das jemals committet wurde – auch vor Jahren und später gelöscht –, gilt als offengelegt, wenn ein solcher Workflow laufen konnte. Erst rotieren, dann die Historie bereinigen.
Was ist am 8. Oktober passiert?
Laut StepSecurity nutzte der Angreifer zuerst das Konto von Takashi Kitao, um den bösartigen Workflow in 27 Repositories zu pushen. Rund acht Stunden später wurde über das Konto von Henry Wu dieselbe Datei in 318 Repositories gepusht, die meisten davon Forks – innerhalb von 16 Minuten. Beide Schübe liefen automatisiert: ein Commit pro Repository, der eine einzelne Workflow-Datei mit harmlos klingendem Namen anlegt oder ändert.
Socket, das dieselbe Welle unabhängig analysierte, zählte 346 betroffene Repositories, darunter uber/athenadriver und kitao/pyxel. Bei mehreren geprüften Repositories lag die Datei am 9. Oktober noch im Default-Branch. Bis Redaktionsschluss hatte Socket keine bösartigen Paketversionen auf PyPI oder crates.io gesehen, die gestohlenen Tokens würden genau das aber ermöglichen. The Hacker News bezifferte unter Berufung auf Socket den Gesamtumfang auf mehr als 500 kompromittierte Konten und Zehntausende Repositories seit dem 7. Oktober.
Was stiehlt der bösartige Workflow?
Frühere GhostAction-Wellen sammelten die benannten Secrets ein, die die Workflows eines Repositorys referenzieren, etwa Publishing-Tokens für PyPI, npm und Docker Hub. GitGuardian zählte in der ursprünglichen Kampagne 2025 auf diesem Weg 3.325 gestohlene Secrets. Die neue Version behält das bei und ergänzt einen zweiten Schritt: Sie checkt das Repository mit fetch-depth: 0 aus, führt git log -p --all aus und durchsucht die komplette Historie mit regulären Ausdrücken.
Die Muster decken AWS-Access-Keys (einschließlich temporärer STS-Keys), API-Keys von Anthropic, OpenAI und OpenRouter, Personal Access Tokens von GitHub und GitLab, Keys für Google, Firebase und GCP sowie Zugangsdaten für Slack und SendGrid ab. Ein Key, der 2022 versehentlich committet und im nächsten Commit wieder entfernt wurde, ist also weiterhin betroffen. Die Ergebnisse werden im Klartext übertragen – jeder, der den Netzwerkpfad mitlesen kann, sieht sie ebenfalls.
Was das für Software-Teams in den USA und der EU bedeutet
Erstens: Ziel ist die Pipeline, nicht der Code. Der Angreifer braucht keine Schwachstelle in Ihrer Anwendung. Ein einziges Maintainer-Token mit Schreibrechten genügt, um mit Ihren Secrets Code in Ihrer CI auszuführen. Teams, die jeden Pull Request zur Anwendung reviewen, Workflow-Dateien aber ohne Review ändern lassen, haben ihre stärksten Kontrollen an der falschen Stelle. Die Regeln für .github/workflows sollten mindestens so streng sein wie die für die Produktionskonfiguration Ihres Cloud- und DevOps-Setups.
Zweitens: KI-API-Keys sind inzwischen wertvolle Beute. Der Workflow sucht neben Cloud-Zugangsdaten gezielt nach Keys von Anthropic, OpenAI und OpenRouter. Ein geleakter Modell-Key ist eine direkte Rechnung und – für Teams, die Kundendaten an Modelle senden – ein Risiko für den Datenzugriff. Solche Keys gehören in einen Secret-Manager mit Ausgabenlimits und getrennten Keys pro Umgebung, nicht in .env-Dateien, die in Commits landen.
Drittens: Regulierer behandeln das als Vorfall, nicht als Aufräumarbeit. Konnte ein gestohlener Cloud-Key personenbezogene Daten erreichen, können die Meldefristen der DSGVO greifen; NIS2, DORA und SOC 2 erwarten zudem eine dokumentierte Rotation von Secrets und Zugriffsprüfungen. Ein datierter Nachweis, welche Repositories geprüft, welche Läufe ausgeführt und welche Keys rotiert wurden, ist genau das, wonach ein Prüfer fragen wird.
Was bedeutet GhostAction für Unternehmen im DACH-Raum?
Im DACH-Raum laufen viele Builds nicht nur auf GitHub, sondern auch auf selbst gehosteten GitLab-Instanzen – doch der Workflow sucht in der Historie ausdrücklich auch nach GitLab-Tokens. Wer Code zwischen beiden Welten spiegelt oder Forks von Open-Source-Projekten pflegt, sollte beide Plattformen prüfen. Besonders im Mittelstand und bei Agentur-Projekten liegen Cloud- und KI-Keys erfahrungsgemäß noch als langlebige Zugangsdaten in alten Commits, statt über einen Secret-Manager oder OIDC-Föderation bezogen zu werden.
Rechtlich ist ein abgeflossener Key kein reines Technikthema: Nach Art. 33 DSGVO ist eine Datenschutzverletzung in der Regel binnen 72 Stunden der zuständigen Aufsichtsbehörde zu melden, wenn über den Key personenbezogene Daten erreichbar waren. In der Schweiz verlangt das revidierte Datenschutzgesetz eine Meldung an den EDÖB „so rasch als möglich“. Hersteller von Software mit digitalen Elementen müssen zudem seit dem 11. September 2026 nach dem Cyber Resilience Act schwerwiegende Vorfälle, die die Sicherheit ihres Produkts beeinträchtigen, an das zuständige CSIRT und die ENISA melden – eine kompromittierte Release-Pipeline kann genau so ein Fall sein. Dokumentieren Sie Prüfung, Rotation und Entscheidung über die Meldung deshalb von Anfang an.
Was sollten Teams jetzt tun?
- Nach den Dateien suchen. Durchsuchen Sie Ihre Organisation nach
security-audit.yml,github_actions_security.yml,security-check.ymlund der IP 193.32.204.199 in Workflow-Dateien – einschließlich Forks und archivierter Repositories. - Die Run-Logs prüfen. Suchen Sie nach Actions-Läufen seit dem 7. Oktober, die Sie nicht gestartet haben. Ist der Workflow gelaufen, gilt jedes Secret, das er lesen konnte, als verloren.
- Erst rotieren, dann bereinigen. Rotieren Sie offengelegte Actions-Secrets und jeden Key, der jemals in der Git-Historie stand. Eine umgeschriebene Historie macht einen bereits erfolgten Diebstahl nicht rückgängig.
- Änderungen an Workflows absichern. Verlangen Sie Code-Owner-Reviews für
.github/workflows, schützen Sie Default-Branches und begrenzen Sie, welche Konten und Tokens pushen dürfen. - Verkleinern, was ein Job stehlen kann. Nutzen Sie kurzlebige Cloud-Zugangsdaten per OIDC statt langlebiger Keys, binden Sie Secrets an Environments und setzen Sie das Standard-
GITHUB_TOKENauf Nur-Lesen.
Häufige Fragen
Was ist die GhostAction-Kampagne?
GhostAction ist ein Lieferkettenangriff auf GitHub Actions, der erstmals im September 2025 auftrat. Die Angreifer nutzen kompromittierte Entwicklerkonten, um eine Workflow-Datei hinzuzufügen, die Repository-Secrets an einen Server der Angreifer schickt. Eine neue Welle am 8. Oktober 2026 nutzte die Konten des pyxel-Autors und des ursprünglichen Autors von Ubers athenadriver und traf rund 345 Repositories.
Woran erkenne ich, ob mein Repository betroffen ist?
Durchsuchen Sie Ihre Repositories einschließlich Forks nach Workflow-Dateien namens security-audit.yml, github_actions_security.yml oder security-check.yml sowie nach der IP-Adresse 193.32.204.199. Prüfen Sie anschließend die GitHub-Actions-Logs seit dem 7. Oktober 2026 auf Läufe, die Sie nicht gestartet haben. Ist der bösartige Workflow gelaufen, sind seine Secrets als gestohlen zu behandeln.
Reicht es, einen geleakten Key aus dem Code zu löschen?
Nein. Die neue Variante liest mit git log -p --all die komplette Git-Historie, sodass auch ein committeter und später gelöschter Key gefunden werden kann. Rotieren Sie den Key zuerst beim Anbieter und entfernen Sie ihn danach bei Bedarf aus der Historie.
Nach welchen Zugangsdaten sucht der Workflow?
Er sammelt die GitHub-Actions-Secrets, die die Workflows des Repositorys verwenden, und durchsucht Code und Historie nach AWS-Keys, API-Keys von Anthropic, OpenAI und OpenRouter, GitHub- und GitLab-Tokens, Keys für Google, Firebase und GCP sowie Zugangsdaten für Slack und SendGrid.
Muss ein Unternehmen in Deutschland den Vorfall melden?
Das hängt davon ab, was über die gestohlenen Keys erreichbar war. Konnten personenbezogene Daten betroffen sein, ist nach Art. 33 DSGVO in der Regel binnen 72 Stunden die Datenschutzaufsicht zu informieren; NIS2-pflichtige Einrichtungen haben zusätzliche Meldepflichten gegenüber dem BSI. Dokumentieren Sie Prüfung und Entscheidung in jedem Fall.
Wie lassen sich ähnliche Angriffe verhindern?
Verlangen Sie Code-Owner-Reviews für Änderungen unter .github/workflows, schützen Sie Default-Branches, erzwingen Sie starke Authentifizierung für Maintainer-Konten, setzen Sie das Standard-GITHUB_TOKEN auf Nur-Lesen, binden Sie Secrets an Environments und ersetzen Sie langlebige Cloud-Keys durch kurzlebige OIDC-Zugangsdaten.
Quellen
StepSecurity — GhostAction Returns: Malicious “Security Audit” Workflows Now Mine Credentials from Entire Git Histories
Socket — New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials
The Hacker News — Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories
GitGuardian — The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows