TanStack-Supply-Chain-Angriff: Wie bösartige Pakete npm-Installationen kompromittierten

Ein manipuliertes npm-Paket infiltrierte die Supply-Chain von TanStack und stahl Entwickler-Credentials – doch der Angriff hätte jeden treffen können. Hier die genauen Abläufe und Schutzmaßnahmen.

Am 11. Mai 2026 wurde eine gezielte Attacke auf das Ökosystem von TanStack bekannt, die durch eine Kombination aus GitHub-Actions-Schwachstellen und npm-Cache-Manipulation 84 bösartige Paketversionen in 42 @tanstack/*-Modulen veröffentlichte. Der Angreifer nutzte dabei eine bekannte, aber oft unterschätzte Sicherheitslücke: die unsichere Nutzung von pull_request_target in Workflows. Obwohl kein Maintainer gezielt kompromittiert wurde, demonstriert der Vorfall, wie anfällig selbst etablierte Open-Source-Projekte für Supply-Chain-Angriffe sind.

Der Angriff: Drei Schwachstellen in einem Workflow

Der Angreifer eröffnete einen Pull Request in einem Fork des TanStack/router-Repositories. Obwohl die Maintainer den PR nie prüften und sofort schlossen, löste der Workflow bundle-size.yml aus – und zwar aufgrund der gefährlichen Konfiguration von pull_request_target. Diese GitHub-Actions-Eigenschaft führt Code im privilegierten Kontext des Basis-Repositorys aus, ohne zusätzliche Sicherheitsprüfungen für Erstbeitragende.

Der Workflow führte folgenden Befehl aus:

pnpm nx run @benchmarks/bundle-size:build

Dabei wurde der Code des Angreifers ausgeführt, der gezielt den npm-Cache manipulierte. Als kurze Zeit später ein legitimer Merge aus einem anderen PR den Release-Workflow auslöste, nutzte der kompromittierte Cache die Gelegenheit, um ein kurzlebiges Publish-Token aus dem Arbeitsspeicher des Runners zu extrahieren. Mit diesem Token veröffentlichte der Angreifer innerhalb von nur sechs Minuten zwei Wellen bösartiger Versionen der Pakete – zwischen 19:20 und 19:26 UTC.

Die Schadsoftware: Credential-Diebstahl und automatisierte Verbreitung

Wer eine der kompromittierten Versionen installierte, lud nicht nur ein harmloses Paket herunter, sondern auch eine versteckte Malware. Die npm install- oder pnpm install-Befehle lösten die Ausführung von router_init.js aus, einer skriptbasierten Payload in den optionalDependencies des Pakets. Das Schadprogramm durchsuchte systematisch gängige Speicherorte für Entwickler-Credentials:

• Lokale Konfigurationsdateien wie ~/.npmrc

• GitHub-Tokens aus Umgebungsvariablen, der gh-CLI oder .git-credentials

• SSH-Privatschlüssel

• Cloud-Runner-Zugänge (AWS, GCP, Kubernetes, Vault)

Die gestohlenen Daten wurden über den verschlüsselten Messenger Session an einen externen Server übertragen – ein sogenannter Dead Drop. Die Kommunikation verblieb im normalen Session-Datenverkehr, sodass selbst Netzwerküberwachungen die Exfiltration nicht erkennen konnten. Einziger wirksamer Schutz wäre das Blockieren der Session-Domains auf Netzwerkebene.

Ein weiteres Ziel der Malware war die automatische Verbreitung: Ein kompromittierter Entwicklerrechner oder CI-Runner diente als Sprungbrett für die nächste Infektionswelle. Durch die Manipulation des Paket-Ökosystems hätte der Angreifer theoretisch eine Kettenreaktion auslösen können, bei der kompromittierte Maintainer zu neuen Angriffsvektoren werden.

Wer war betroffen? Die betroffenen Pakete im Überblick

Insgesamt wurden 42 Pakete in 84 Versionen kompromittiert, veröffentlicht in zwei Wellen am 11. Mai 2026. Die betroffenen Paketfamilien umfassen:

• @tanstack/router
• @tanstack/react-router
• @tanstack/solid-router
• @tanstack/vue-router

Nicht betroffen waren hingegen die Pakete @tanstack/query, @tanstack/table, @tanstack/form, @tanstack/virtual, @tanstack/store sowie das Meta-Paket @tanstack/start.

Wichtig: Jeder, der am 11. Mai 2026 eine der kompromittierten Versionen installiert hat, muss davon ausgehen, dass der Installationshost potenziell kompromittiert wurde. Die Angriffsindikatoren (IOCs) lassen sich an zwei Merkmalen erkennen:

• Ein Eintrag in optionalDependencies mit dem Verweis auf eine bestimmte GitHub-Commit-Referenz

• Eine Datei router_init.js im Wurzelverzeichnis des betroffenen Pakets

Sofortmaßnahmen: So schützen Sie sich vor ähnlichen Angriffen

Die TanStack-Maintainer haben die kompromittierten Versionen bereits deaktiviert und die Paket-Tarballs aus dem npm-Registry entfernt. Dennoch sollten Sie folgende Schritte ergreifen:

1. Prüfen Sie Ihre Lockfiles

• Durchsuchen Sie Ihre package-lock.json, pnpm-lock.yaml oder yarn.lock nach Einträgen mit @tanstack/* vom 11. Mai 2026.
• Achten Sie auf verdächtige optionalDependencies-Einträge, die auf externe GitHub-Commits verweisen.

1. Rotieren Sie alle Credentials

• Falls Sie eine kompromittierte Version installiert haben, müssen Sie alle Zugänge rotieren, die von diesem Host aus erreichbar waren:
• Cloud-Anbieter (AWS, GCP, Azure)
• GitHub, npm, Docker Hub
• Kubernetes-Cluster
• SSH-Schlüssel und Vault-Secret
• Nutzen Sie Passwort-Manager oder geheime Umgebungsvariablen, um die Rotation zu vereinfachen.

1. Pinnen Sie auf sichere Versionen

• Installieren Sie nur noch Paketversionen, die nach dem 11. Mai veröffentlicht wurden.
• Nutzen Sie exakte Versionen in Ihren package.json, um unbeabsichtigte Updates zu vermeiden.

1. Auditing Ihrer GitHub-Workflows

• Überprüfen Sie alle Workflows, die pull_request_target verwenden und Code aus Forks ausführen.
• Nutzen Sie Tools wie zizmor, um Workflows nach unsicheren Mustern zu durchsuchen.

Lehren aus dem Vorfall: Warum pull_request_target gefährlich ist

Der Angriff macht deutlich, dass pull_request_target ein unverantwortliches Risiko darstellt – und das seit Jahren. Die GitHub-Actions-Dokumentation warnt seit 2023 vor dieser Konfiguration, doch viele Projekte nutzen sie weiterhin aus Bequemlichkeit oder Unwissenheit.

Die Risiken sind offensichtlich:

• Keine Erstbeitragenden-Prüfung: Code aus Forks wird im Kontext des Basis-Repositorys ausgeführt – ohne zusätzliche Sicherheitshürden.

• Cache-Poisoning: Durch die Manipulation des Caches wird bösartiger Code in legitime Workflows eingeschleust.

• Token-Exfiltration: Kurzlebige Publish-Tokens oder andere sensible Daten liegen im Arbeitsspeicher des Runners und sind angreifbar.

Empfehlung: Ersetzen Sie pull_request_target durch sichere Alternativen wie pull_request mit expliziter Genehmigung oder verwenden Sie workflow_run für CI/CD-Pipelines. Ein einmaliger Audit Ihrer Workflows kann Sie vor ähnlichen Angriffen schützen.

Der TanStack-Vorfall zeigt: Supply-Chain-Angriffe werden immer raffinierter. Doch mit proaktiven Maßnahmen, transparenten Audits und der Abschaffung unsicherer Workflow-Muster können Entwicklerteams das Risiko deutlich minimieren – bevor der nächste Angriff zuschlägt.