TanStack Supply-Chain-Angriff: Anatomie einer dreistufigen Sicherheitsverletzung

FinOps in the CI: Cost Guardrails at Provisioning Time

Shifting cloud cost governance into the pipeline — Infracost cost estimates, OPA/Rego policy gates, OpenCost runtime monitoring, and the three-phase adoption path to hard-deny budgets.

Am 11.05.2026 zwischen 19:20 und 19:26 UTC veröffentlichte ein Angreifer 84 bösartige Versionen über 42 @tanstack/* npm-Pakete hinweg. Der Angriff erforderte drei verschiedene Schwachstellen, von denen keine allein ausreichend gewesen wäre. TanStack hat eine ausführliche Postmortem-Analyse veröffentlicht; dieser Artikel extrahiert die technischen Details, die jeder DevOps-Engineer heute in seinen eigenen Pipelines prüfen sollte.

Die dreistufige Angriffskette

Stufe 1: pull_request_target Cache Poisoning

Der Einstiegspunkt des Angreifers war ein Fork-PR gegen TanStack/router. Der bösartige PR (#7378), der vom Account zblgg aus eröffnet wurde, nutzte den pull_request_target Trigger in bundle-size.yml aus:

on:
  pull_request_target:
    paths: ["packages/**", "benchmarks/**"]

jobs:
  benchmark-pr:
    steps:
      - uses: actions/checkout@v6.0.2
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge

      - uses: TanStack/config/.github/setup@main
      # ↑ Transitively calls actions/cache@v5

      - run: pnpm nx run @benchmarks/bundle-size:build
      # ↑ Executes attacker code in the build step

pull_request_target wird mit Schreibberechtigungen auf dem Basis-Repository ausgeführt und checkt den gemergten Code des PR aus. Der Workflow-Autor beabsichtigte eine Trennung des Vertrauens zwischen „nicht vertrauenswürdigem“ PR-Code und schreibgeschützten Berechtigungen, aber das Post-Job-Save von actions/cache@v5 wird nicht durch permissions: contents: read beschränkt. Cache-Schreibvorgänge verwenden ein Runner-internes Token. Der Build des PR vergiftete den pnpm-Store unter einem Key, den der Produktions-Workflow release.yml später berechnen und wiederherstellen würde.

Als release.yml bei einem Push auf main ausgeführt wurde, stellte es den vergifteten Cache wieder her – vom Angreifer kontrollierte Binärdateien befanden sich nun auf der Festplatte innerhalb des Kontextes des Release-Workflows.

Stufe 2: OIDC Token Memory Extraction

release.yml deklarierte id-token: write rechtmäßig für das npm OIDC Trusted Publishing. Als der vergiftete pnpm-Store wiederhergestellt wurde, wurden diese Binärdateien während des Build-Schritts aufgerufen. Diese führten dann folgende Schritte aus:

1. Lokalisierung des GitHub Actions Runner.Worker-Prozesses via /proc/*/cmdline
2. Lesen von /proc/<pid>/maps und /proc/<pid>/mem, um den Speicher des Workers zu dumpen
3. Extraktion des OIDC-Tokens (das lazy im Speicher erstellt wird, wenn id-token: write gesetzt ist)
4. Verwendung des Tokens für einen direkten POST an registry.npmjs.org – wodurch der „Publish Packages“-Schritt des Workflows vollständig umgangen wurde

Dies ist dieselbe Memory-Extraction-Technik und dasselbe wortwörtliche Python-Skript, das bei der tj-actions/changed-files Kompromittierung im März 2025 verwendet wurde. Kein neuartiges Vorgehen – sondern eine Rekombination bereits veröffentlichter Forschung.

Stufe 3: Selbstausbreitung

Das prepare Lifecycle-Skript der Malware listete zudem andere Pakete auf, die das Opfer verwaltet (registry.npmjs.org/-/v1/search?text=maintainer:<user>), und veröffentlichte diese mit derselben Injektion erneut. Dies ist ein Wurm – nicht nur Diebstahl von Zugangsdaten, sondern eine laterale Ausbreitung über das gesamte Paket-Portfolio des Opfers.

Auswirkungen

Die Payload installierte einen Dead-Man's-Switch: ~/.local/bin/gh-token-monitor.sh als systemd-User-Service (Linux) oder LaunchAgent (macOS). Dieser pollt alle 60 Sekunden api.github.com/user. Wenn das gestohlene Token widerrufen wurde, während die infizierte Maschine noch online war, führte das Skript rm -rf ~/ aus.

Zeitstrahl

Detection IOCs

Für Security-Teams, die Downstream-Scans durchführen:

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}

• Datei im betroffenen Tarball: router_init.js (~2,3 MB, Paket-Root, nicht in „files“)
• Cache-Key: Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11
• Exfiltrations-Netzwerk: filev2.getsession.org, seed{1,2,3}.getsession.org
• Gefälschte Commit-Identität: claude <claude@users.noreply.github.com> (fabriziert, nicht Anthropic)
• Angreifer-Accounts: zblgg (GitHub ID 127806521), voicproducoes

Was die Postmortem-Analyse richtig macht

Die Analyse von TanStack ist bemerkenswert für ihre Offenheit:

• Keine internen Alarme haben die Kompromittierung erkannt – ein Drittanbieter-Forscher meldete sie zuerst.
• pull_request_target Workflows wurden nie geprüft, obwohl sie ein seit langem bekanntes gefährliches Muster darstellen.
• Floating Action Refs (@v6.0.2, @main) erzeugen ein dauerhaftes Supply-Chain-Risiko, unabhängig von diesem Vorfall.
• Die OIDC Trusted-Publisher-Bindung hat keine Review pro Veröffentlichung: Einmal konfiguriert, kann jeder Codepfad im Workflow ein veröffentlichungsfähiges Token erstellen.
• Die npm-Richtlinie „kein Unpublish, wenn Abhängigkeiten existieren“ verhinderte die direkte Entfernung; man musste sich darauf verlassen, dass npm Security die Tarballs serverseitig entfernt.

Dem Angreifer war zudem Glück beschieden: Seine Payload beschädigte die Tests, was dazu führte, dass der Publish-Schritt (der sauberer aussehende Tarballs produziert hätte) übersprungen wurde. Ein vorsichtigerer Angreifer hätte stundenlang unbemerkt veröffentlichen können.

Hardening-Checkliste

Wenn Sie pull_request_target Workflows betreiben, prüfen Sie diese auf folgende spezifische Bedingungen:

pull_request_target

# NEVER do this — checkout of fork PR head inside a workflow with write permissions
- uses: actions/checkout@v6.0.2
  with:
    ref: refs/pull/${{ github.event.pull_request.number }}/merge
# Instead: use github.event.pull_request.head.repo.full_name to detect cross-repo
# Or: use a separate "untrusted" job that has NO write permissions and NO cache access

GitHub Actions Cache

• Der Cache-Scope ist pro Repository und wird zwischen pull_request_target und main Branch-Workflows geteilt
• Das actions/cache@v5 Post-Job-Save wird nicht durch permissions: contents: read eingeschränkt
• Mitigation: Verwendung separater Cache-Keys pro Trigger-Kontext oder vollständige Deaktivierung des Cache-Restore für nicht vertrauenswürdige Trigger

- uses: actions/cache@v5
  if: github.event_name == 'push' && github.ref == 'refs/heads/main'
  # ↑ Only save cache for trusted contexts

OIDC Trusted Publishing

• id-token: write erstellt bei der ersten Verwendung verzögert (lazy) ein Token im Runner-Speicher
• Jeder Angreifer-Code, der auf dem Runner ausgeführt wird, kann dieses extrahieren
• Mitigation: GitHub Environments mit manuellen Approval-Gates für Publish-Workflows
• Weitere Mitigation: Manuelle Genehmigung auf Seiten der npm-Registry anfordern (noch keine Standardpraxis)

environment: publish # Configure environment protection rules in GitHub settings
permissions:
  id-token: write
  contents: read

Weitreichendere Auswirkungen

Die Security-Community dokumentiert pull_request_target Cache Poisoning bereits seit 2024 (Adnan Khan, "The Monsters in Your Build Cache"). Dieser Angriff zeigt, dass bekannte, dokumentierte Muster aktiv und in großem Stil gegen hochkarätige Open-Source-Projekte ausgenutzt werden.

Die Kette verdeutlicht, dass OIDC Trusted Publishing zwar eine Verbesserung gegenüber statischen Token darstellt, aber nicht verhindert, dass eine kompromittierte CI-Pipeline bösartige Pakete veröffentlicht. Der zweite Faktor – auf der Seite von npm – bleibt die Schwachstelle: Sobald ein OIDC-Token innerhalb eines Workflows erstellt wurde, kann jeder Code in diesem Workflow ihn zum Veröffentlichen nutzen.

Das selbstpropagierende Design (das Aufzählen und erneute Veröffentlichen anderer Pakete des Opfers) stellt eine Eskalation vom reinen Supply-Chain-Angriff hin zu einer automatisierten lateralen Bewegung dar. Hier geht es nicht mehr nur um den Diebstahl von Zugangsdaten – es geht darum, die eigene Infrastruktur zur Paketveröffentlichung in ein Malware-Distributionsnetzwerk zu verwandeln.

Referenzen

• TanStack tracking issue
• GitHub Security Advisory GHSA-g7cv-rxg3-hmpx
• GitHub Security Lab: Preventing pwn requests
• Adnan Khan: Monsters in Your Build Cache (Mai 2024)