Aufgefallen war die Kampagne, kurz nachdem schädliche Paket-Artefakte über die legitime Release-Pipeline von TanStack veröffentlicht worden waren und sich der Angriff von dort auf weitere Pakete ausbreitete. Anders als bei früheren TeamPCP-Angriffen, die auf gestohlenen Geheimnissen zum Übernehmen von Konten beruhten, verkettete der TanStack-Angriff laut StepSecurity drei bekannte Schwachstellenklassen, um 84 schädliche Artefakte über 42 Pakete auszuliefern.
In einer Aufarbeitung beschreibt TanStack die Kette als Kombination aus einer Fehlkonfiguration vom Typ „pull_request_target Pwn Request", einer Vergiftung des GitHub-Actions-Caches über die Vertrauensgrenze zwischen Fork und Basis sowie dem Auslesen des OIDC-Tokens aus dem Arbeitsspeicher des Actions-Runners. Laut Wiz benannten die Angreifer ihren Fork des TanStack/router-Repositorys in zblgg/configuration um und öffneten einen Pull Request, der den pull_request_target-Workflow auslöste, den Schadcode ausführte und den Cache vergiftete. Wurden später echte Maintainer-Pull-Requests in den Hauptzweig zusammengeführt, stellte der Release-Workflow den vergifteten Cache wieder her, woraufhin angreifergesteuerte Binärdateien die OIDC-Tokens aus dem Speicher extrahierten.
Mit dem gestohlenen GitHub-OIDC-Token konnten sich die Angreifer ein Signaturzertifikat verschaffen und die schädlichen Pakete mit einer scheinbar gültigen SLSA-Provenance versehen. Snyk erklärt, dieses kryptografische, über Sigstore erzeugte Zertifikat solle eigentlich belegen, dass ein Paket aus einer vertrauenswürdigen Quelle stammt – der Wurm konnte es erzeugen, weil er die legitime Build-Pipeline selbst kaperte. Snyk hebt hervor, dass gerade der Missbrauch dieser Provenance-Attestierung den Angriff bemerkenswert macht: Die schädlichen Pakete sind von legitimen nicht zu unterscheiden.
In jedes der 42 TanStack-Pakete wurde derselbe 2,3 MB große Implant (router_init.js) direkt in das Paket-Tarball eingeschleust. Laut Socket handelt es sich um einen mehrstufigen Credential-Stealer, der die Umgebung zunächst auswertet – Betriebssystem, CI-Plattform und JavaScript-Laufzeit – und anschließend systematisch jede erreichbare Geheimnisebene moderner Cloud-CI-Umgebungen durchsucht. Die erbeuteten Zugangsdaten werden über drei Kanäle abgezogen: die Domain git-tanstack[.]com, das Session-Netzwerk (Exfiltration über *.getsession.org) sowie über „Dune"-thematische GitHub-Repositorys, die mit gestohlenen Tokens erstellt werden. Den Session-Kanal bezeichnet Wiz als neu und wegen seiner dezentralen, schwer abschaltbaren Struktur als deutlich schwerer zu unterbinden.
Zur NPM-Verbreitung nutzt der Wurm laut Socket die OIDC-Föderation von GitHub Actions, um im Namen der kompromittierten CI-Identität ein gültiges NPM-Publish-Token zu erzeugen. Über die GitHub-GraphQL-API committet er zudem Kopien seiner selbst in die Repositorys der betroffenen Maintainer, wobei der Commit-Autor gefälscht wird, um die Anthropic-Claude-Code-GitHub-App vorzutäuschen.
Die schädlichen PyPI-Versionen von Guardrails AI und Mistral AI enthielten laut Wiz eine andere Schadlast. Im Guardrails-AI-Paket luden 13 Zeilen neuen Codes eine nicht obfuskierte Schadlast von git-tanstack[.]com nach – einen modularen Credential-Stealer, der nur unter Linux läuft und erstmals auch Passwortmanager wie 1Password und Bitwarden ins Visier nimmt. Auf Systemen mit israelischer oder iranischer Spracheinstellung versuchte die Malware, eine MP3-Datei in voller Lautstärke abzuspielen und Dateien zu löschen.
Laut SafeDep traf die Kampagne am 11. Mai mehr als 170 Pakete; mindestens 401 schädliche Artefakte wurden innerhalb von fünf Stunden veröffentlicht. Einige betroffene Pakete wie die im TanStack-Namespace verzeichnen Millionen wöchentlicher Downloads; das TanStack-Router-Paket kommt in Anwendungen mit React, Vue und Solid zum Einsatz. Bei Mistral AI waren der Kern-SDK sowie die Azure- und GCP-Integration betroffen, jeweils mit drei schädlichen Versionen. Hinzu kamen 65 schädliche Versionen von UiPath-NPM-Paketen, der OpenSearch-JavaScript-Client sowie fünf schädliche Versionen von 20 Squawk-Paketen.
Betroffenen wird geraten zu prüfen, ob kompromittierte Versionen in ihre Umgebung gelangt sind, die Systeme zu bereinigen und alle möglicherweise offengelegten Zugangsdaten zu erneuern. Snyk empfiehlt zudem, GitHub-Actions-OIDC-Konfigurationen und pull_request_target-Workflows auf Cache-Vergiftung zu überprüfen und ergänzend zur Provenance-Prüfung eine Verhaltensanalyse zur Installationszeit einzusetzen.