Mini Shai-Hulud: TanStack, OpenAI und die Supply Chain

Die jüngste Supply-Chain-Kampagne hat nicht nur Open-Source-Register kompromittiert. Sie hat auch die Release-Pipeline innerhalb einer der sicherheitsbewusstesten Organisationen der Welt gekapert, und der Einstiegspunkt war eine routinemäßige Installation einer npm-Abhängigkeit.

Am 11. Mai 2026 führte die Hackergruppe TeamPCP die vierte Welle ihrer Shai-Hulud-Wurmkampagne durch, die nun unter dem Namen „Mini Shai-Hulud“ verfolgt wird. Der Angriff kompromittierte innerhalb von sechs Minuten 84 bösartige Paketversionen in 42 TanStack-Paketen im npm-Register und breitete sich schließlich auf mehr als 170 Pakete in den Quellcode-Registern von npm und PyPI (Python Package Index) aus, darunter Namespaces von Mistral AI, UiPath und OpenSearch. Mindestens ein betroffenes Paket, @tanstack/react-router, verzeichnet wöchentlich etwa 12 Millionen Downloads.

Dies ist die vierte Welle einer eskalierenden Kampagne. Zu den vorherigen Wellen zählen der ursprüngliche Angriff auf npm (Shai-Hulud 1.0) sowie die 2.0-Welle, die auf GitHub-Anmeldedaten abzielte.

OpenAI gab diese Woche bekannt, dass zwei Geräte von Mitarbeitern kompromittiert wurden. Es waren weder Nutzerdaten noch Produktionssysteme oder geistiges Eigentum betroffen, doch die Eindämmungsmaßnahmen erforderten die Isolierung von Systemen, die Erneuerung von Zugangsdaten, die Hinzuziehung externer Forensik-Experten sowie eine vollständige Erneuerung der Code-Signing-Zertifikate für macOS, Windows, iOS und Android, die durch die Installation einer einzigen Abhängigkeit ausgelöst wurde.

• Datum des Angriffs: 11. Mai 2026

• Betroffene Pakete: 84 schädliche Versionen in 42 Paketen der Reihe @tanstack/*; insgesamt über 170 in den Registern von npm und PyPI

• CVE: CVE-2026-45321, CVSS-Wert 9,6 (kritisch)

• Urheber: TeamPCP (auch bekannt als PCPcat, UNC6780)

• Mechanismus: Drei miteinander verknüpfte Sicherheitslücken in GitHub Actions – Pwn Request, Cache Poisoning, Extraktion von OIDC-Tokens (OpenID Connect) aus dem Speicher des Runner-Prozesses

• Bemerkenswertes Opfer: OpenAI – zwei Geräte von Mitarbeitern wurden kompromittiert; vertrauliche Informationen, darunter Code-Signing-Zertifikate für macOS, iOS, Windows und Android, wurden aus internen Quellcode-Repositorys abgezogen

• Vorherige Phasen: Shai-Hulud 1.0 (September 2025), 2.0 (November 2025) und 3.0 (Dezember 2025)

• Auswirkungen: Kompromittierte Entwicklungs- und CI/CD-Umgebungen, Übernahme von Betreuerkonten und Paketen sowie SLSA-Provenienz und signierte Builds, die nicht mehr „standardmäßig sicher“ sind

• Wesentliche Risiken: Schädliche Pakete, die die Herkunftsbescheinigung der SLSA-Stufe 3 (Supply-Chain Levels for Software ) bestehen

„Mini Shai-Hulud Wave Four“ ist die technisch ausgefeilteste Variante dieser Kampagne bis heute. Während frühere Angriffe darauf abstellten, über kompromittierte Maintainer-Konten direkt schädliche Pakete zu veröffentlichen, nutzte „Wave Four“ drei Schwachstellen in GitHub Actions aus, um die legitime Release-Pipeline selbst zu kapern.

Der Ablauf des Angriffs:

1. Fork und Tarnung: Der Angreifer hat das Repository „TanStack/router“ geforkt und in „zblgg/configuration“ umbenannt, damit es in den Fork-Listenansichten von GitHub nicht als offensichtlicher Fork erkennbar war.
2. Workflow auslösen: Es wurde ein Pull-Request erstellt, der den Workflow „pull_request_target“ ausgelöst hat – das Muster „Pwn Request“, das dem Workflow Zugriff auf den geforkten Code gewährt
3. Den Cache manipulieren: Der Code der vom Angreifer erstellten Fork-Instanz schrieb einen manipulierten 1,1-GB-Eintrag für „pnpm-store“ in den GitHub-Actions-Cache, der so gekennzeichnet war, dass der Release-Workflow ihn später wiederherstellen würde
4. Spuren verwischen: Der böswillige Pull-Request wurde anschließend zwangsweise in einen inaktiven Zustand versetzt und geschlossen, um die Spuren des Angriffs zu verwischen
5. Warten Sie auf den Auslöser: Als legitime TanStack-Betreuer nicht zusammenhängende Pull-Anfragen in den Hauptzweig einpflegten, wurde der Release-Workflow ausgelöst und der manipulierte Cache wiederhergestellt
6. Steal the token: Attacker-controlled binaries read /proc/<pid>/mem of the Runner.Worker process to extract the OIDC token minted for npm trusted publishing
7. Veröffentlichung über die Pipeline: Diese Tokens wurden genutzt, um 84 schädliche Paketversionen über die eigene, legitime Release-Pipeline von TanStack in der npm-Registry zu veröffentlichen.
8. Das Ergebnis: Pakete, die gültige SLSA-Build-Level-3-Herkunftsbescheinigungen, gültige Sigstore-Bescheinigungen und legitime GitHub-Actions-Signaturen aufweisen, von der legitimen Release-Pipeline erstellt wurden und Malware enthalten, die Zugangsdaten stiehlt. Wie TanStack in seiner Nachbetrachtung bestätigte, erschienen die Pakete aus Sicht der Entwickler kryptografisch authentisch, ohne sichtbare Anzeichen für eine Kompromittierung.

Geheimnisse wurden offengelegt: Die Malware-Nutzlast exfiltrierte offengelegte Geheimnisse – Anmeldedaten und Token, auf die auf den kompromittierten Systemen aktiv zugegriffen werden konnte – über drei redundante Kanäle: eine Typosquatting-Domain (git-tanstack[.]com), das dezentrale Session-Messenger-Netzwerk und API unter Verwendung gestohlener Token. Zu den ins Visier genommenen Anmeldedaten gehörten GitHub-Token, Cloud-Geheimnisse von AWS, GCP und Azure, CI/CD-Authentifizierungsdaten, Kubernetes-Anmeldedaten, H Vault und SSH-Schlüssel.

Auf den Rechnern der Entwickler installierte die Malware einen dauerhaft laufenden „gh-token-monitor“-Daemon (über den macOS LaunchAgent oder Linux systemd), der alle 60 Sekunden eine Abfrage an GitHub sendete. Nach Erhalt eines 40X-Fehlers aufgrund einer Token-Sperrung versuchte der Daemon, den Befehl „rm -rf ~/“ auszuführen, um das Home-Verzeichnis des Benutzers zu löschen. Der Daemon beendete sich nach 24 Stunden automatisch.

In der Mitteilung von OpenAI wird genau angegeben, welche Daten abgezogen wurden: Es handelt sich um eine begrenzte Menge an Anmeldedaten aus einem Teil der internen Quellcode-Repositorys, auf die die beiden betroffenen Mitarbeiter Zugriff hatten, darunter Code-Signatur-Zertifikate für Produkte unter macOS, iOS, Windows und Android. OpenAI bestätigte, dass es keine Hinweise darauf gibt, dass diese Zertifikate zur Signierung von Schadsoftware verwendet wurden, wechselt jedoch vorsorglich alle Zertifikate aus und fordert macOS-Nutzer auf, ihre Anwendungen bis zum 12. Juni 2026 zu aktualisieren; danach funktionieren mit den alten Zertifikaten signierte Apps möglicherweise nicht mehr.

Ein weiteres Detail in der Mitteilung von OpenAI verdient Beachtung. Auf den beiden kompromittierten Geräten waren die aktualisierten Konfigurationen für die Paketverwaltung – darunter Kontrollmechanismen wie die Überprüfung des Mindestalters von Releases und die Validierung der Herkunft von Paketen –, die gerade unternehmensweit eingeführt wurden, noch nicht installiert. Der Angriff erfolgte während dieses Einführungszeitraums.

Dies beschreibt eine reale und weit verbreitete Sicherheitslücke. Sicherheitsmaßnahmen werden schrittweise eingeführt. Bei jeder schrittweisen Einführung ist ein Teil der Systeme einem höheren Risiko ausgesetzt. Die Kampagne von TeamPCP lief über mehrere Wochen hinweg ununterbrochen, wobei bösartige Pakete in Registries veröffentlicht wurden und darauf gewartet wurde, dass sie installiert werden. Der Zeitpunkt war kein Zufall.

Für alle Organisationen, die während des „Mini Shai-Hulud“-Zeitraums möglicherweise betroffene Pakete installiert haben:

1. Überprüfen Sie vor dem Widerrufen von Tokens, ob der gh-token-monitor-Daemon läuft: Isolieren und erstellen Sie zunächst Images der betroffenen Systeme; ein vorzeitiges Widerrufen löst die Löschfunktion aus.
2. Wechseln Sie offen liegende Zugangsdaten: GitHub-PATs, npm-Token, SSH-Schlüssel und Cloud-Anmeldedaten für alle Entwickler oder Pipelines, die während des betroffenen Zeitraums Pakete installiert haben; aktivieren Sie die Zwei-Faktor-Authentifizierung.
3. Kompromittierte Pakete entfernen: npm-Cache und node_modules löschen; auf Paketversionen festlegen, die nach dem 12. Mai 2026 veröffentlicht wurden.
4. Überprüfen Sie GitHub Actions und CI/CD-Workflows: Achten Sie auf unerwartete Veröffentlichungsereignisse, neue Workflows oder ausgehende Verbindungen zu unbekannten Endpunkten.
5. Pipelines absichern: Lebenszyklus-Skripte einschränken, ausgehenden Netzwerkzugriff begrenzen und Token-Umfang minimieren.
6. Kombinieren Sie Herkunftsprüfungen mit Inhaltsprüfungen: Eine gültige Herkunftsangabe gibt Aufschluss über die Herkunft der Pipeline, nicht über deren Integrität; führen Sie neben der Überprüfung der Zertifikate auch Malware-Scans durch.