WFX-Angriff auf GitHub: Manipulierte Workflows stehlen Secrets

Seit dem 10. November 2026 schleusen Angreifer über gestohlene GitHub-Zugänge Schadcode in Repositories ein. Die Kampagne wird als wfx, wfx-loot und WFX Phantom untersucht. Aikido-Bericht vom 12. November

Der untersuchte Einstieg erfolgt über gültige Zugänge. StepSecurity beschreibt keine dafür ausgenutzte neue Sicherheitslücke der GitHub-Plattform. Für Unternehmen ist deshalb entscheidend, welche Rechte ein betroffener Entwickler- oder Bot-Zugang hatte. StepSecurity-Analyse

Wie groß ist der Angriff?

Die veröffentlichten Zahlen zählen unterschiedliche Ereignisse:

Quellen: Aikido, SafeDep. Die Werte sind weder addierbar noch eine gemeinsame Quote. Ein Probe-PR bedeutet nicht automatisch, dass Schadcode ausgeführt wurde. Aus diesen Beobachtungen lässt sich auch keine vollständige Zahl betroffener privater Repositories ableiten.

Was zwischen dem Commit und dem Revert passiert

Die Angreifer tarnen Änderungen als gewöhnliche Wartungsarbeit. Dazu gehören Ergänzungen in vorhandenen Workflows, bereits verwendeten Shell-Skripten und package.json. Nach dem Start folgt teilweise ein Revert; Workflow-Läufe samt Logs werden gelöscht. Neuere untersuchte Varianten nutzen auch Telegram für den Datenabfluss. StepSecurity

Das erschwert die nachträgliche Prüfung. Wer nur den aktuellen Branch ansieht, kann eine zwischenzeitlich eingeschleuste Änderung übersehen. Umgekehrt ist eine Lücke in der Laufnummerierung allein kein Beweis für WFX. Commit-Verlauf, Audit-Ereignisse und vorhandene Laufprotokolle müssen zusammenpassen.

Ein konkreter Vorgang ist bei WebdriverIO öffentlich dokumentiert: Ein am 11. November angelegter Pull Request beschreibt zwei unerlaubte Commits unter dem Bot-Konto. Sie ergänzten ein verstecktes Shell-Skript und änderten den postinstall-Hook im Projekt. Der Beitrag fordert ausdrücklich, die Bot-Berechtigungen und mögliche Paketveröffentlichungen zu prüfen.

Dieser Fund betrifft damit auch die Frage, ob ein Projektstand lokal installiert wurde. Ein ausschließlich auf den Actions-Tab begrenztes Review wäre zu eng. Der PR dokumentiert die Repository-Manipulation; daraus folgt nicht pauschal, dass alle veröffentlichten WebdriverIO-Pakete schädlich waren.

Welche Spuren Teams suchen können

Für die erste Suche nennt Aikido unter anderem wfx-docs, den PR-Titel docs: dependency audit notes und den Commit-Titel ci: refresh build cache. Indikatoren im Bericht

Prüft solche Treffer inhaltlich. Ein ähnlich benannter legitimer Wartungscommit ist noch kein Sicherheitsvorfall. Relevant sind die tatsächlichen Änderungen, die verwendete Identität und eine mögliche Ausführung. Bezieht auch Bot-Konten, Organisations-Repositories und von Workflows aufgerufene Skripte ein.

Notiert Commit-ID, Repository, Zeitpunkt und betroffenen Lauf, soweit diese Informationen vorliegen. Die Untersuchung sollte Originalbelege sichern, statt verdächtige Dateien auf einem produktiven Entwicklerrechner testweise auszuführen.

Warum auch die Cloud geprüft werden muss

SafeDep beschreibt Versuche, AWS-Zugänge und Vertrauensregeln sowie Azure-Föderationszugänge zu verändern. Ihr Erfolg hängt von den Berechtigungen ab; eine erfolgreiche Übernahme sämtlicher angebundener Clouds ist nicht belegt. SafeDep-Analyse

Auch kurzlebige Zugänge über OpenID Connect (OIDC) gehören in die Untersuchung. Bei diesem Verfahren prüft der Cloud-Anbieter Merkmale des Workflows und stellt daraufhin einen zeitlich begrenzten Zugang aus. Ein manipulierter Workflow kann weiterhin dieselben zugelassenen Identitätsmerkmale besitzen. Entscheidend sind deshalb die Vertrauensbedingungen und Rechte der Cloud-Rolle. GitHub zu OIDC

Für die Wiederherstellung folgt daraus: Token-Austausch, Bereinigung des Repositories und Prüfung neu angelegter Cloud-Zugänge benötigen jeweils einen eigenen Abschlussnachweis.

Paketfund ist nicht gleich Ausführung

SafeDep fand einen npm-Hook in digitalelvis/neuronai-studio 3.14.3 und manipulierte Workflows in Go-Projektständen. Reguläres composer install beziehungsweise go get führt diese Mechanismen laut Analyse nicht aus. Paketanalyse

Für eine belastbare Betroffenheitsprüfung braucht ihr daher Paketstand und ausgeführten Arbeitsablauf. „Paket vorhanden“ und „Schadcode lief mit diesen Zugängen“ sind unterschiedliche Befunde.

Was bei einem konkreten Treffer zuerst ansteht

Aus den Berichten und den Plattformhinweisen ergibt sich folgende Prüfreihenfolge für betroffene Teams:

1. Weitere Ausführung verhindern und Spuren sichern. Verdächtige Jobs stoppen, betroffene Automatisierung begrenzen und verfügbare Logs sowie Commit- und Audit-Daten sichern. Eine frisch zurückgesetzte Datei ist kein ausreichender Abschluss.
2. Kompromittierte Zugänge beim Aussteller widerrufen. GitHub empfiehlt bei offengelegten Secrets zunächst Widerruf oder Rotation. Das Entfernen aus Dateien macht ein Secret nicht ungültig. Neue Zugangsdaten sollten erst in eine kontrollierte Umgebung gelangen. GitHub-Hinweise
3. Den Zugriffsumfang rekonstruieren. Welche Secrets, Registries und Cloud-Rollen waren dem betroffenen Job oder Rechner zugänglich? Prüft damit verbundene Veröffentlichungen und Zugriffe im fraglichen Zeitraum. Bei KI-Schlüsseln gehören auch Nutzung und entstandene Kosten dazu.
4. Cloud-Berechtigungen und Runner untersuchen. Vergleicht Rollen, Schlüssel und föderierte Identitäten mit dem freigegebenen Zustand. Bezieht selbst betriebene Runner und Entwicklerrechner ein, wenn dort eine Ausführung möglich war. Entscheidet anhand der Befunde, welche Umgebung neu aufgebaut werden muss.
5. Den Wiederanlauf getrennt freigeben. Prüft den bereinigten Quellstand, die verwendeten Abhängigkeiten und den Veröffentlichungsweg. Dokumentiert, welche alten Zugänge widerrufen und welche Dienste mit neuen Zugängen getestet wurden.

npm --ignore-scripts kann automatische Installationsskripte unterbinden. Es ist jedoch keine Sandbox: Ein ausdrücklich gestartetes npm run, npm test oder vergleichbares Skript kann weiterhin ausgeführt werden. Verdächtige Projekte gehören deshalb in eine dafür eingerichtete Untersuchungsumgebung. npm-Dokumentation

Welche Schutzregeln jetzt ein Review verdienen

GitHub empfiehlt minimale Rechte für GITHUB_TOKEN, eingeschränkte Workflow-Zugänge und Freigaben für geschützte Umgebungen. Prüft besonders, wer Workflows ändern, an Secrets gelangen oder Schutzregeln umgehen darf. Ein Bot mit weitreichenden Ausnahmen muss in dieses Review einbezogen werden. GitHub-Sicherheitshinweise

Noch nicht vollständig geklärt sind der Gesamtumfang und die ursprüngliche Herkunft sämtlicher gestohlener Zugänge. Die genannten Zahlen sind datierte Beobachtungen der Forschungsteams. Sie ersetzen keine Prüfung der eigenen Organisation.

Für die interne Koordination braucht es einen gemeinsamen Stand: betroffene Repositories, gesicherte Befunde, widerrufene Zugänge, untersuchte Cloud-Änderungen und offene Wiederanlaufprüfungen. In Kopexas Vorfallmanagement lässt sich diese Arbeit mit Verantwortlichen und Nachweisen nachverfolgen.

Quellenstand: 13. November 2026. Die Grafik ist eine eigene schematische Darstellung des Angriffsablaufs, keine GitHub-Produktoberfläche.