Mini Shai-Hulud und TanStack: Warum CI/CD-Sicherheit zur Chefsache wird

Der Supply-Chain-Angriff auf TanStack ist ein Warnsignal für jedes Unternehmen, das moderne JavaScript-, TypeScript- oder Python-Abhängigkeiten nutzt. Am 11. Mai 2026 zwischen 19:20 und 19:26 UTC wurden laut TanStack 84 kompromittierte Versionen von 42 @tanstack/*-Paketen auf npm veröffentlicht. Die Veröffentlichung lief nicht über ein klassisches „npm-Token gestohlen”-Szenario, sondern über die legitime GitHub-Actions-Release-Pipeline.

Genau deshalb ist der Fall so relevant: Die kompromittierten Pakete sahen nicht aus wie ein plumper Fremdkörper neben der Pipeline. Die Angreifer missbrauchten das Vertrauensmodell der Pipeline selbst – mit pull_request_target, GitHub-Actions-Cache-Poisoning und der Extraktion eines OIDC-Tokens aus dem Runner-Prozess.

Was ist passiert?

TanStack beschreibt eine Angriffskette, die drei Sicherheitsannahmen miteinander verkettete. Ein Angreifer öffnete einen Pull Request aus einem Fork. Ein Workflow mit pull_request_target lief im Kontext des Ziel-Repositories und führte Code aus dem Pull-Request-Kontext aus. Diese Klasse von Fehlern ist als „Pwn Request”-Muster bekannt; GitHub Security Lab warnt seit Jahren davor, untrusted PR-Code in privilegierten Workflows auszuführen.

Der zweite Baustein war GitHub-Actions-Cache-Poisoning. Der Angreifer brachte schadhaften Inhalt in den pnpm-Store-Cache ein. Dieser Cache wurde später vom legitimen Release-Workflow auf main wiederhergestellt. Der dritte Baustein war OIDC-Token-Extraktion: Weil der Release-Workflow für npm Trusted Publishing berechtigterweise id-token: write nutzte, konnte die Malware ein OIDC-Token aus dem Runner-Kontext gewinnen und direkt gegen registry.npmjs.org veröffentlichen.

Warum TanStack ein Warnsignal für moderne DevOps-Prozesse ist

Der TanStack-Fall ist kein Randproblem für Open-Source-Maintainer. Er zeigt eine strukturelle Schwachstelle vieler DevOps-Setups: CI/CD-Runner sind häufig die Stelle, an der Quellcode, Build-Artefakte, Cloud-Zugangsdaten, Deployment-Rechte und Paketveröffentlichungen zusammenlaufen. Wer dort Code ausführen kann, steht oft sehr nah an produktiven Schlüsseln.

Besonders unangenehm ist die Rolle von Provenance. StepSecurity hebt hervor, dass die kompromittierten Pakete teilweise gültige SLSA-Level-3-Provenance-Attestations hatten. Das ist kein Widerspruch: Provenance kann zeigen, dass ein Paket aus der erwarteten Pipeline stammt. Sie beweist aber nicht, dass diese Pipeline während des Builds sauber war.

Der eigentliche Vertrauensbruch fand nicht neben der Release-Pipeline statt, sondern in ihr. Das macht den Vorfall für Unternehmen so gefährlich.

Betroffene Pakete und Umfang

Für TanStack bestätigt das offizielle Postmortem 42 betroffene Pakete mit jeweils zwei kompromittierten Versionen. Nicht betroffen waren laut TanStack unter anderem @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store und das Meta-Package @tanstack/start selbst. Betroffen waren dagegen verschiedene Router-, Start- und Adapter-Pakete.

Die Kampagne war größer als TanStack. SafeDep beschreibt eine koordinierte Aktion gegen über 170 npm-Pakete und zwei PyPI-Pakete mit insgesamt 404 schadhaften Versionen. Aikido zählt zum Analysezeitpunkt 373 malicious package-version entries über 169 npm-Paketnamen. Diese Abweichung ist bei laufenden Untersuchungen normal: Datenquellen, Zeitpunkte und Zählweisen unterscheiden sich.

Weitere in Berichten genannte Ökosysteme und Paketgruppen waren unter anderem @uipath/*, @mistralai/mistralai, @opensearch-project/opensearch, @squawk/* und @tallyui/*. Für eine operative Prüfung sollten Teams nicht nur nach TanStack suchen, sondern auch Dependency- und Registry-Scanner gegen die laufend aktualisierten Advisory-Daten laufen lassen.

Was die Malware stehlen wollte

Die TanStack-Pakete enthielten laut Advisory eine etwa 2,3 MB große obfuskierte JavaScript-Datei namens router_init.js. Sie konnte bei npm install, pnpm install oder yarn install über den Installationspfad ausgeführt werden. Der Payload zielte auf Zugangsdaten, die in Entwicklerumgebungen und CI/CD besonders wertvoll sind.

• GitHub-Tokens aus Umgebungsvariablen, gh-CLI-Konfiguration und .git-credentials
• npm-Tokens aus ~/.npmrc
• AWS Instance Metadata Service und AWS Secrets Manager
• GCP Metadata Service
• Kubernetes-Service-Account-Tokens
• HashiCorp-Vault-Tokens
• SSH-Private-Keys

Die Exfiltration lief unter anderem über filev2.getsession.org sowie seed1.getsession.org, seed2.getsession.org und seed3.getsession.org. Wiz nennt zusätzlich git-tanstack[.]com und die IP 83.142.209[.]194 als relevante Netzwerkindikatoren. Diese IOCs sollten in DNS-, Proxy- und EDR-Telemetrie geprüft werden.

PyPI-Variante: gleiche Kampagne, anderer Mechanismus

Neben npm waren laut SafeDep auch PyPI-Pakete betroffen, darunter mistralai==2.4.6 und guardrails-ai==0.10.1. Die Python-Variante nutzte einen anderen Mechanismus: Beim Import wurde ein Dropper ausgeführt, der transformers.pyz von einer attacker-kontrollierten Domain herunterlud und mit python3 startete.

Wiz beschreibt weitere Details der Python-Variante, darunter Linux-spezifische Ausführungsbedingungen, Abbruchlogik bei bestimmten Systemmerkmalen und zusätzliche Exfiltrationsziele. Diese Details sind für Detection nützlich, sollten aber als laufende Threat-Intel-Lage behandelt werden: Bei aktiven Supply-Chain-Kampagnen können sich Payloads, Infrastruktur und Paketlisten schnell ändern.

Warum gültige Provenance nicht automatisch Sicherheit bedeutet

Trusted Publishing, OIDC und SLSA-Provenance sind sinnvolle Bausteine. Sie reduzieren langfristige Publish-Tokens, schaffen nachvollziehbare Herkunftsinformationen und erschweren klassische Token-Diebstahl-Szenarien. Der TanStack-Vorfall zeigt aber ihre Grenze: Wenn untrusted Code über Cache oder Build-Schritte in den Release-Kontext gelangt, kann die Pipeline weiterhin formal „echt” sein und trotzdem schadhaft bauen oder veröffentlichen.

Für Security-Teams heißt das: Herkunftsnachweise sind ein Signal, kein Freifahrtschein. Entscheidend bleibt, ob die Pipeline zwischen untrusted Pull Requests, Build-Caches, Testjobs und Publish-Rechten klare Grenzen zieht. Ein Release-Workflow mit id-token: write sollte nur Code ausführen, der diesen Vertrauensstatus wirklich verdient.

Sofortmaßnahmen für Entwickler- und Security-Teams

Die wichtigste operative Frage lautet: Wurde am 11. Mai 2026 eine betroffene Version auf einem Entwicklergerät, CI-Runner, Build-Image oder Deployment-Host installiert? Wenn ja, sollte das System nicht nur als „Dependency betroffen”, sondern als mögliche Credential-Exposition behandelt werden.

rg -n "router_init\.js|router_runtime\.js|tanstack_runner\.js|setup\.mjs|@tanstack/setup|79ac49eedf774dd4b0cfa308722bc463cfe5885c" .

rg -n "@tanstack/(history|react-router|router-core|router-utils|router-plugin|virtual-file-routes|router-generator|start-|react-start|solid-|vue-|zod-adapter|valibot-adapter|arktype-adapter|eslint-plugin-start|eslint-plugin-router)" package-lock.json pnpm-lock.yaml yarn.lock bun.lockb

Eine sinnvolle Sofortreaktion besteht aus fünf Schritten:

CI/CD-Workflows auditieren

Der langfristig wichtigste Teil ist ein Audit der Build- und Release-Workflows. Suchen Sie insbesondere nach pull_request_target, nach Cache-Wiederverwendung zwischen untrusted PRs und main, nach Workflows mit id-token: write und nach Publish-Rechten, die in Test-, Benchmark- oder Analysejobs verfügbar sind.

rg -n "pull_request_target|id-token:\s*write|actions/cache|trusted.?publish|npm publish|pypi|twine" .github/workflows

Gute Zielbilder für GitHub Actions:

• pull_request_target nur für Metadaten-Aktionen wie Labels oder Kommentare verwenden, nicht für Checkout und Ausführung von Fork-Code.
• Caches strikt nach Vertrauensgrenze trennen: untrusted PR-Jobs dürfen keine Artefakte erzeugen, die Release-Jobs auf main später blind wiederverwenden.
• id-token: write nur in minimalen Publish-Jobs setzen, nicht in Test-, Benchmark- oder Build-Jobs mit großer Codeausführungsfläche.
• Third-Party-Actions auf Commit-SHAs pinnen und nicht dauerhaft auf Floating Refs wie @main oder breite Major-Tags vertrauen.
• Paketveröffentlichungen monitoren: Wer hat wann welche Version aus welchem Workflow veröffentlicht, und passte das zum erwarteten Release-Schritt?

Indicators of Compromise

Die folgenden Indikatoren eignen sich für eine erste Suche. Sie ersetzen keine vollständige Incident-Response-Analyse, helfen aber, schnell zwischen „wahrscheinlich nicht betroffen” und „muss untersucht werden” zu unterscheiden.

Langfristige Schutzmaßnahmen für Unternehmen

Mini Shai-Hulud ist kein Argument gegen Open Source. Es ist ein Argument dafür, Software-Lieferketten wie produktive Systeme zu behandeln. Wer Abhängigkeiten baut, testet und veröffentlicht, betreibt faktisch eine kleine Produktionsumgebung mit hoher Auswirkung auf Kunden, Systeme und Daten.

Fazit: CI/CD ist ein Hochrisiko-System

Der Mini-Shai-Hulud-/TanStack-Vorfall zeigt, dass Unternehmen ihre CI/CD-Pipelines wie produktive Hochrisiko-Systeme behandeln müssen: mit minimalen Rechten, klarer Trennung von vertrauenswürdigen und untrusted Workflows, sauberer Secret-Hygiene, Monitoring und geübten Incident-Response-Prozessen.

Provenance, Trusted Publishing und OIDC bleiben wichtige Bausteine. Aber sie schützen nur dann, wenn die Pipeline selbst vertrauenswürdig bleibt. Der entscheidende Kontrollpunkt liegt nicht erst im Paket-Registry-Account, sondern viel früher: bei jedem Workflow, der untrusted Code annimmt, Caches schreibt oder Release-Rechte berühren kann.

Häufige Fragen

Diese FAQ ist als schnelle Betroffenheitsprüfung gedacht: Wenn Sie ein Projekt, einen CI-Runner oder ein Entwicklergerät untersuchen, starten Sie mit Lockfiles, Installationszeitpunkt, IOCs und Secret-Exposition.