wfx-loot: Gekaperte GitHub-Konten schleusen Secret-Stealer in über 1.800 Repositories

Über 4.800 übernommene GitHub-Konten haben seit dem 10. November 2026 Test-Pull-Requests in mehr als 61.000 Repositories geöffnet und danach in Tausenden davon Schadcode eingeschleust, der in GitHub Actions Secrets und Cloud-Zugänge abgreift. Das berichtet das Sicherheitsunternehmen Aikido Security am 12. November 2026, das die Kampagne „wfx-loot“ nennt. Laut Aikido öffneten 4.837 Konten Test-Pull-Requests in 61.764 Repositories, in mindestens 1.835 Repositories lief der Schadcode und leitete Zugangsdaten aus.

Betroffen sind Organisationen, deren Entwickler- oder Bot-Konten zu den übernommenen gehören oder die solchen Konten Schreibrechte geben. Wer GitHub Actions mit Cloud-Zugängen nutzt, sollte heute prüfen, ob die beschriebenen Spuren in den eigenen Repositories auftauchen.

Was ist passiert?

Der Angreifer arbeitet laut Aikido und dem zweiten Analysten StepSecurity mit gültigen Zugangsdaten echter Konten. Eine Lücke in GitHub Actions nutzt er laut StepSecurity nicht. Wie er an die Tokens kam, ist offen. Der Ablauf je Repository:

• Zuerst ein Test-Pull-Request mit dem Titel „docs: dependency audit notes“ aus dem Branch wfx-docs, der nur die Datei docs/wfx-audit.md anlegt.
• Danach der eigentliche Schadcode: rund 1.500 Zeilen in einem bestehenden Workflow (Commit „ci: refresh build cache“), ein neuer Workflow auf einem Wegwerf-Branch chore/… (Commit „chore: add dependency audit workflow“), ein versteckter postinstall-Hook in package.json (Commit „chore: add ci helper“) oder Code, der an ein bestehendes Shell-Skript der CI angehängt wird.
• Zum Schluss ein Revert („ci: restore“, teils „ci: cleanup“) und das Löschen des Workflow-Laufs samt Logs.

Das Skript sammelt laut Aikido alle Actions-Secrets und Variablen, das GITHUB_TOKEN, Zugangsdateien für AWS, Azure, GCP, Docker, Kubernetes, npm, PyPI, SSH und Vault sowie Schlüssel für KI-Dienste. Über OIDC tauscht es Tokens gegen Cloud-Sitzungen und versucht, in AWS und Azure eigene Hintertüren einzurichten, soweit die Rechte reichen. StepSecurity beobachtete ab dem 12. November zusätzlich eine Variante, die Daten über die Telegram-API ausleitet.

Wer ist betroffen?

Rund 10.400 der Test-Pull-Requests gingen laut Aikido in Repositories, die dem Konto gar nicht gehören, sondern über Collaborator- oder Organisationszugriff erreichbar waren. Laut Aikido waren 92 Prozent der Test-Pull-Requests noch offen. Mindestens 50 der übernommenen Konten veröffentlichen offenbar Pakete für npm, Go, Packagist, PyPI oder crates. Aikido nennt bislang das Packagist-Paket digitalelvis/neuronai-studio 3.14.3 und das Go-Modul github.com/onuragtas/docker-env in v1.0.278 und v1.0.280 als belastet. StepSecurity nennt zusätzlich eine Version von github.com/vkuznet/gocurl. Bei den Go-Modulen steckt der Schadcode laut Aikido nur in einer Workflow-Datei.

Wie kritisch ist das?

Aikido schreibt sinngemäß: Lief der Schadcode in einem Repository, gelten alle Secrets und Cloud-Rollen dieser Workflows als kompromittiert. Weil der Angreifer die Logs löscht, helfen sie bei der Suche kaum. Beide Analysten nennen eine Lücke in der Nummerierung der Workflow-Läufe direkt nach dem verdächtigen Commit als wichtiges, oft einziges Zeichen. Die Zahlen stammen aus den Messungen der beiden Anbieter, eine Stellungnahme von GitHub lag in den gelesenen Quellen nicht vor.

Was sollten Admins jetzt tun?

• Inventar: in allen Repositories nach Pull Requests „docs: dependency audit notes“, Branches wfx-docs und chore/… sowie den Commit-Titeln „ci: refresh build cache“, „chore: add dependency audit workflow“, „chore: add ci helper“, „ci: restore“ und „ci: cleanup“ suchen.
• Workflow-Läufe seit dem 10. November auf fehlende Laufnummern prüfen, ergänzend das Audit-Log der Organisation auf gelöschte Läufe.
• Treffer: alle Secrets, Tokens und Cloud-Rollen rotieren, die der Workflow erreichen konnte, nicht nur die offensichtlichen.
• Hintertüren entfernen: in AWS Trust Policies mit "Principal": {"AWS": "*"} und neue Zugangsschlüssel prüfen, in Azure Federated Credentials mit dem Namen wfx-ci-… löschen.
• Betroffene Konten: persönliche Zugriffstokens, OAuth-Freigaben und SSH-Schlüssel widerrufen, Bot-Konten mit Ausnahmen beim Branch-Schutz überprüfen.
• Härtung: ausgehenden Verkehr von Runnern begrenzen, Secrets nur den Jobs geben, die sie brauchen.

Einordnung für Unternehmen

Die Kampagne zeigt erneut, dass ein einzelnes Entwicklerkonto mit weitreichenden Rechten genügt, um Cloud-Umgebungen ganzer Organisationen zu öffnen. Schon im Oktober hatte GhostAction über präparierte Workflows Zugangsdaten gestohlen. Aikido und StepSecurity sehen Überschneidungen bei Konten und Repositories, Aikido hält die Kampagnen wegen anderer Infrastruktur und Werkzeuge aber für getrennt. Wer Secrets zentral in einem Tresor verwaltet und kurzlebige Zugänge nutzt, begrenzt den Schaden.

Passende Anleitungen auf S-EDV

• GhostAction: Fake-Workflows stehlen GitHub-Secrets in Repos
• Infisical mit Docker installieren: Open-Source-Plattform für Secrets Management
• OpenBao mit Docker unter Linux installieren: zentraler Secrets-Store unter MPL-2.0

Quellen

• Aikido Security: Analyse der Kampagne wfx-loot
• StepSecurity: Analyse des Secret-Stealers
• BleepingComputer: 4.800 GitHub-Konten übernommen
• SecurityWeek: Angriff auf 60.000 Repositories