GhostAction: Fake-Workflows stehlen GitHub-Secrets in Repos
Die GhostAction-Kampagne verteilt getarnte Workflows, die Actions-Secrets und per Git-Historie auch alte Cloud-, KI- und Token-Zugangsdaten an eine feste IP schicken. Socket nennt mehr als 500 Konten. Admins sollten Workflow-Dateien prüfen, Konten sperren und Secrets rotieren.
Eine Kampagne mit dem Namen GhostAction schleust seit Wochen getarnte Workflow-Dateien in GitHub-Repositories ein und liest damit Zugangsdaten aus. Am 8. Oktober 2026 trafen zwei übernommene Maintainer-Konten innerhalb weniger Minuten 346 Repositories, darunter das Uber-Projekt athenadriver und die Spiele-Engine pyxel, so die Analyse von Socket. Nach einem Update vom 9. Oktober sieht Socket mehr als 500 beteiligte Konten und Zehntausende betroffene Repositories seit dem 7. Oktober.
Betroffen sind vor allem Teams, deren Maintainer-Zugänge, Personal Access Tokens oder Forks mit dem Angriff in Berührung kamen. Wer keine Repositories auf GitHub betreibt, ist nicht direkt betroffen. Wer GitHub Actions nutzt, sollte heute prüfen, ob eine der unten genannten Dateien existiert. Das ist eine Sache von Minuten und kein Wartungsfenster.
Was ist passiert?
Die Angreifer nutzen gestohlene GitHub-Zugangsdaten von Maintainern, vermutlich aus Infostealer-Logs oder Credential-Dumps. Das ist laut StepSecurity eine plausible Annahme, belegt ist es nicht. Mit dem Konto des Maintainers wird direkt in den Default-Branch eine Datei .github/workflows/security-audit.yml committet, getarnt als Sicherheitsverbesserung. Die Commit-Meldung lautet "Add security audit workflow". Der Commit trägt die echte Identität des Opfers, ist unsigniert und läuft ohne Pull Request.
Laut StepSecurity pushte der Angreifer am 8. Oktober ab 13:20 UTC über das Konto von Takashi Kitao, Autor der Spiele-Engine pyxel, den Workflow in 27 Repositories. Acht Stunden später folgten über das Konto von Henry Wu (henrywoo) 318 Repositories in einem Zeitfenster von 16 Minuten, darunter 279 Forks. Der Workflow läuft bei jedem Push und per manuellem Start, lädt die komplette Git-Historie und schickt Funde per HTTP-POST an die feste IP-Adresse 193.32.204.199. Auf dem Weg gibt es keine DNS-Abfrage, domainbasierte Filter greifen also nicht.
Neu gegenüber der Welle von 2025 ist die Suche in der gesamten Historie. Der Workflow sammelt nicht nur die benannten Actions-Secrets, sondern durchsucht Arbeitsverzeichnis und alle Branches und Tags nach 13 Mustern, darunter AWS-Schlüssel, API-Schlüssel von Anthropic, OpenAI und OpenRouter sowie Tokens für GitHub und GitLab. Auch längst gelöschte Zugangsdaten sind damit betroffen.
Wer ist betroffen?
Direkt betroffen sind Repositories, in denen eine der beiden Dateien security-audit.yml oder github_actions_security.yml auftaucht. GitGuardian zählte zwischen dem 31. August und dem 30. September 2026 772 öffentliche Repositories von 373 Nutzern und Organisationen mit dem älteren Workflow. Mittelbar gefährdet sind Forks: Wer einen Fork aus einem betroffenen Namensraum anlegt oder synchronisiert, erbt die Datei, und mit aktivierten Actions kann sie anlaufen. Private Forks und Spiegel gelten als besonders exponiert, weil dort tatsächlich committete Zugangsdaten liegen.
Nicht betroffen ist, wer weder ein kompromittiertes Konto mit Schreibrechten besitzt noch Forks aus den genannten Namensräumen verwendet. Eine Schwachstelle in GitHub Actions selbst ist nicht die Ursache. Der Zugang kommt über gestohlene Konten.
| Quelle | Angabe | Zeitraum |
|---|---|---|
| StepSecurity | 345 Repositories, zwei Konten | 8. Oktober 2026 |
| Socket | 346 Repositories, davon 279 Forks im Namensraum henrywoo | 8. Oktober 2026 |
| Socket (Update) | mehr als 500 Konten, Zehntausende Repositories | seit 7. Oktober 2026 |
| StepSecurity (Codesuche) | 378 Repositories mit aktivem Workflow im Default-Branch | Stand 9. Oktober 2026 |
| GitGuardian | 772 Repositories, 2.577 Secrets im Visier | 31. August bis 30. September 2026 |
Die Zahlen weichen ab, weil sie unterschiedliche Methoden und Stichtage nutzen. Die Angabe "Zehntausende" stammt aus dem Socket-Update und wurde von den übrigen Quellen nicht unabhängig bestätigt.
Wie kritisch ist das?
Die Ausnutzung ist belegt. StepSecurity hat das Run-Log von uber/athenadriver ausgewertet: Der Server des Angreifers bestätigte den Empfang vier Sekunden nach Start des Workflows. Bei pyxel lief der Workflow fünfmal erfolgreich, zweimal davon per manuellem Start aus der übernommenen Sitzung, was auf Handarbeit hindeutet. Die gezielt eingetragenen Secrets von pyxel sind Zugänge zu PyPI, crates.io und ein GitHub-Token, also Publishing-Rechte.
Bisher gibt es laut Socket und StepSecurity keine bösartigen Paketversionen, die mit den gestohlenen Zugängen veröffentlicht wurden. Das ist kein Entwarnungssignal, solange die Tokens nicht rotiert sind. Der GITHUB_TOKEN der Läufe war in den untersuchten Fällen auf contents: read beschränkt. Der Schaden hängt daher an den entwendeten Secrets und an alten Zugangsdaten in der Historie.
Ein Kontrollpunkt hat nachweislich gewirkt: Im Repository typecho-fans/plugins blieben zwei erneute Auslöseversuche im Status "action_required" stehen, weil dort die Freigabe von Workflow-Läufen verlangt wird. Dort lief die Datenübertragung nicht ab. GitGuardian beobachtete im September Ähnliches, die meisten Läufe warteten auf Freigabe.
Was sollten Admins jetzt tun?
- Inventar prüfen: Alle Repositories und Forks der Organisation sowie der Konten mit Schreibrechten auf die Dateien
security-audit.yml,github_actions_security.ymlundsecurity-check.ymldurchsuchen. - In der GitHub-Codesuche nach
"AKIA_CTX_START","c=monami"und"193.32.204.199"im Pfad.github/workflowssuchen, getrennt für die eigene Organisation. - Bei einem Fund das gesamte Konto als kompromittiert behandeln: Sitzungen, Personal Access Tokens, OAuth-Freigaben und SSH-Schlüssel widerrufen, danach Multi-Faktor-Authentifizierung erneuern.
- Den Workflow aus allen Branches entfernen, nicht nur aus dem Default-Branch, weil er bei jedem Push auf jedem Branch läuft.
- Alle in Actions hinterlegten Secrets rotieren und zusätzlich jedes Zugangsdatum, das jemals in einem Commit stand. Löschen aus dem aktuellen Stand genügt nicht.
- Bei AWS-Schlüsseln CloudTrail auf neue IAM-Nutzer, Schlüssel und ungewöhnliche Regionen prüfen.
- Bei Publishing-Secrets für PyPI, npm, crates.io oder Container-Registries die Release-Historie auf unerwartete Versionen kontrollieren und bis zur Bereinigung keine Releases bauen.
- Ausgehenden Verkehr der Runner auf Verbindungen zu 193.32.204.199 (Ports 80 und 3000) durchsehen und die Adresse sperren.
- Freigabe für Workflow-Läufe von externen Mitwirkenden verlangen, Push Protection und Secret Scanning aktivieren und Änderungen an
.github/workflows/per Branch-Schutz an Reviews binden.
Eine offizielle Stellungnahme oder Gegenmaßnahme von GitHub zu dieser Welle konnte bis zur Veröffentlichung dieses Beitrags in den genannten Quellen nicht belegt werden.
Einordnung für Unternehmen
Der Fall zeigt, wie weit ein einzelnes gestohlenes Maintainer-Konto reicht. Der Zugriff von Henry Wu auf den Uber-Ableger kam nur daher, dass er das Projekt einst gegründet hatte und Schreibrechte behielt. Ein Konto trägt also das Risiko jeder Organisation, in der es schreiben darf. Auch ehemalige Mitarbeiter und Auftragnehmer sollten regelmäßig aus Organisationen entfernt werden.
Für den Mittelstand gilt: Geheimnisse gehören nicht in die Git-Historie, und Actions-Secrets sind nur so sicher wie der Zugang zum Repository. Kurzlebige Tokens, Secret Scanning vor dem Commit und eine Freigabepflicht für Workflows begrenzen den Schaden spürbar. Rotation allein genügt nicht, solange der Einstiegsweg über das gestohlene Token offen ist.
Passende Anleitungen auf S-EDV
- Gitleaks als Secret-Scanner mit Docker einrichten, um Zugangsdaten in der Git-Historie aufzuspüren
- Docker Compose absichern mit Secrets, Healthchecks und Non-Root
- Vorheriger Vorfall: kompromittierte Actions von actions-cool
Quellen
- Socket Research: New GhostAction Wave Hits Hundreds of Repos (9. Oktober 2026)
- StepSecurity: GhostAction Returns (9. Oktober 2026)
- GitGuardian: The campaign that never stopped (7. Oktober 2026, Update 9. Oktober)
- The Hacker News: Credential-Stealing GitHub Actions Workflows Planted in Tens of Thousands of Repositories
