Nach Angaben von StepSecurity wurde über das Konto von Takashi Kitao, Autor der Spiele-Engine pyxel mit 18.400 Sternen, ab 13:20 UTC ein schädlicher Workflow in 27 Repositories gepusht. Acht Stunden später diente das Konto von Henry Wu (henrywoo), dem ursprünglichen Autor von Ubers athenadriver, dazu, denselben Workflow zwischen 21:10 und 21:26 UTC — also binnen 16 Minuten — in 318 Repositories zu platzieren.
Socket erklärte, bis zum 9. Oktober 2026 mehr als 500 GitHub-Konten identifiziert zu haben, die den bösartigen Workflow seit dem 7. Oktober 2026 in Zehntausende Repositories eingebracht haben.
GhostAction war erstmals im September 2025 öffentlich geworden. Damals waren 817 Repositories von 327 GitHub-Nutzern betroffen; über kompromittierte Entwicklerkonten wurden 3.325 Secrets abgeflossen, darunter Token für PyPI, npm und DockerHub.
Wie zuvor tragen die eingeschleusten Dateien die Namen „Security Audit" (security-audit.yml) beziehungsweise „GitHub Actions Security" (github_actions_security.yml). Sie übertragen die erbeuteten Daten per Klartext-HTTP an die fest hinterlegte IP-Adresse 193.32.204[.]199. Erfasst werden die benannten GitHub-Actions-Secrets eines Repositories, darunter CI/CD-Secrets sowie Cloud-, KI- und SaaS-Zugangsdaten aus dem Arbeitsverzeichnis und der gesamten Git-Historie — etwa AWS-Schlüssel, API-Schlüssel von Anthropic, OpenAI und OpenRouter sowie GitHub- und GitLab-Token.
Die Angriffskette verläuft laut der Analyse in vier Schritten:
- Der Angreifer erlangt GitHub-Zugangsdaten eines Maintainers, höchstwahrscheinlich ein geleaktes Personal Access Token (PAT) aus Infostealer-Logs oder Credential-Dumps.
- In einem Aufklärungsschritt werden die Workflow-Dateien des Repositories nach Secrets durchsucht.
- Ein als Sicherheitsaudit getarnter Workflow wird unter der Identität des Opfers in den Standard-Branch injiziert.
- Die eingebettete Nutzlast extrahiert die Daten und sendet sie per curl an einen vom Angreifer kontrollierten Endpunkt.
„Er wird durch workflow_dispatch und einen ungefilterten Push ausgelöst (jeder Branch, jedes Tag), checkt mit fetch-depth: 0 aus und führt einen einzigen Schritt namens ‚Audit‘ aus, der vier Dinge tut", ergänzte StepSecurity. Konkret hängt der Schritt die bei der Aufklärung gefundenen benannten Secrets an, durchsucht den Arbeitsbaum nach 13 Mustern für Zugangsdaten zu AWS, KI-Diensten, Quellcodeverwaltungen sowie SaaS- und Cloud-APIs, prüft die gesamte Git-Historie auf dieselben 13 Muster, um versehentlich eingecheckte und später gelöschte Zugangsdaten zu bergen, und ordnet AWS-Access-Key-IDs den passenden Secret Access Keys zu.
GitGuardian berichtete Anfang dieser Woche, dass die GhostAction-Kampagne den Schad-Workflow zwischen dem 31. August und dem 30. September 2026 in 772 öffentliche Repositories von 373 GitHub-Nutzern und -Organisationen gepusht hat. Die injizierten Workflows zielen demnach auf 2.577 Secrets ab, darunter private SSH-Schlüssel, Azure-Zugangsdaten, Anmeldedaten für die Container-Registries DockerHub und GHCR, Datenbank-Zugangsdaten, AWS-Access-Keys, FTP-Zugänge, Google-Cloud- und Firebase-Credentials, GitHub-Token, Bot-Token für Telegram, Slack und Discord sowie Schlüssel für Cloudflare, npm, PyPI und KI-Anbieter.
In mindestens einem am 30. August 2026 beobachteten Fall veränderten die Angreifer das Repository „kuafuai/DevOpsGPT" und betteten einen XMRig-Kryptominer in das Docker-Image des Projekts ein. Bislang wurden keine bösartigen Paketveröffentlichungen mit gestohlenen Publishing-Zugangsdaten festgestellt.
Entwicklern wird geraten, ihre Repositories seit dem 31. August 2026 auf die beiden Workflow-Dateien zu prüfen und bei einem Fund von einer Kompromittierung auszugehen: kompromittierte GitHub-Zugangsdaten widerrufen, Credentials rotieren, den Schad-Workflow aus allen Branches löschen und Forks der betroffenen Repositories kontrollieren.
„Die 279 Forks im Namensraum henrywoo tragen jeweils die Workflow-Datei. Sind Actions aktiviert, können nachfolgende Pushes das Abgreifen von Zugangsdaten auslösen", erklärte Socket. Auch nachgelagerte Forks seien gefährdet, wenn sie den bösartigen Workflow erben — bei Neuanlage oder durch Synchronisation mit dem betroffenen Upstream-Repository. Am stärksten exponiert seien private Forks und nachgelagerte Spiegel, weil eingecheckte Zugangsdaten tatsächlich in privaten Repositories zu finden seien. Zudem liefere bei beiden Konten jeder Lauf eine Repository-Kennung zurück, unabhängig davon, ob Zugangsdaten gefunden wurden — der Betreiber verfüge damit über eine Karte erreichbarer Ausführungskontexte, auch ohne jeden Diebstahl von Zugangsdaten.