Technischer Kontext
Ich habe mich direkt nach der Veröffentlichung in die Post-Mortem-Analyse von TanStack vertieft, denn dies ist nicht nur ein weiterer npm-Vorfall. Es ist schlimmer: Die bösartigen Pakete wurden über die offizielle Release-Pipeline veröffentlicht, was bedeutet, dass jedes Team, das KI-Integrationen oder reguläre Produktionsumgebungen auf der Grundlage von Herkunftsnachweisen (Provenance) aufbaut, alarmiert sein sollte.
Das Angriffsfenster war kurz: 11. Mai 2026, von 19:20 bis 19:26 UTC. In diesen sechs Minuten veröffentlichte ein Angreifer 84 bösartige Versionen in 42 @tanstack/*-Paketen.
Die Passwörter der Maintainer wurden nicht gestohlen. Der `npm publish`-Workflow wurde ebenfalls nicht direkt kompromittiert. Der Angreifer manipulierte die CI-Eingaben so, dass die eigene Pipeline von TanStack die infizierten Builds mit ihrer vertrauenswürdigen OIDC-Identität veröffentlichte.
Und hier musste ich wirklich eine Minute innehalten: Die Releases hatten gültige Herkunftsnachweise (Provenance Attestations). Das bedeutet, die übliche Logik „Wenn es eine Signatur und Trusted Publishing gibt, muss es sauber sein“ hat in diesem Fall komplett versagt.
Die Angriffskette war sehr modern. Zuerst nutzten sie das gefährliche `pull_request_target`-Muster, den berüchtigten Pwn Request. Dann vergifteten sie den GitHub-Actions-Cache an der Grenze zwischen dem Fork und dem Basis-Repository. Schließlich extrahierten sie im Release-Job das kurzlebige OIDC-Token direkt aus dem Speicher des Runner-Prozesses.
Im Wesentlichen hat die CI das Token im Moment der Veröffentlichung von sich selbst gestohlen. Das ist keine Geschichte mehr über „Speichern Sie keine Geheimnisse im Repo“. Es ist eine Geschichte darüber, dass Caches, Artefakte und Vertrauensgrenzen (Trust Boundaries) in GitHub Actions standardmäßig als feindlich betrachtet werden sollten.
Wenn Sie @tanstack/* in diesen Tagen bezogen haben, würde ich nicht nur die Version aktualisieren. Ich würde das Projekt mit einer sauberen Lockfile neu erstellen, den Cache leeren, die CI-Protokolle auf seltsame Netzwerkanfragen überprüfen und alle Geheimnisse rotieren, falls das infizierte Paket jemals in der Pipeline ausgeführt wurde.
Was ändert das für Unternehmen und Automatisierung?
Teams, deren Releases auf „Nun, wir haben ja Trusted Publishing“ basieren, sind hier die Verlierer. Die Gewinner sind diejenigen, die nicht vertrauenswürdige PRs, Builds und Veröffentlichungen in verschiedene Vertrauenszonen trennen.
Die zweite Erkenntnis ist noch praktischer: Die Sicherheit der Lieferkette kann nicht mehr manuell mit einer vierteljährlichen Checkliste verwaltet werden. Sie benötigen robuste Richtlinien, Lockfile-Scanning, Cache-Kontrolle, Incident Response und automatisierte Rollbacks.
Bei Nahornyi AI Lab gehen wir genau diese Probleme in der Praxis an: Wir entwerfen KI-Lösungsarchitekturen rund um DevSecOps-Prozesse, damit Teams eine Kompromittierung nicht nachträglich über Protokolle entdecken. Wenn Ihre CI/CD bereits komplex geworden ist und niemand schnell beweisen kann, was sicher ist, lassen Sie uns das analysieren und eine KI-Automatisierung erstellen, die auf Ihren realen Workflow zugeschnitten ist, nicht nur für ein schönes Diagramm in Notion.