Deep Dive: TanStack npm supply-chain compromise

This post is part of my weekly newsletter - Top 5 in Frontend and AI. Subscribe so you can deep dives like this in your inbox

---

If you have pull_request_target anywhere in your workflows, the TanStack compromise could happen to you. Here's exactly how it happened.

On May 11, a new strain of Shai-Hulud worm published 84 malicious versions across 42 @tanstack/* packages by chaining three GitHub Actions vulnerabilities - pull_request_target Pwn (Own) Request, cache poisoning across the fork ↔ base trust boundary, and OIDC token extraction from runner memory. Thankfully, no maintainer was phished and no token was stolen off a laptop.

What happened

An attacker opened a PR from a throwaway fork of TanStack/router . Although the maintainers never got a chance to review the PR since it was immediately closed, the CI workflow was triggered. The damage was already done because the bundle-size.yml workflow ran on pull_request_target, which runs in the base repo's privileged context with no first-time-contributor approval gate in the TanStack repo.

That workflow checked out the fork's PR-merge ref and ran pnpm nx run @benchmarks/bundle-size:build, which executed attacker-controlled code.

The attacker's code poisoned the pnpm cache and later, when an entirely legitimate merge to main, from a different PR, ran the release workflow, it restored that poisoned cache, extracted the short-lived publish token out of the runner's memory, and used it to push malicious versions across router-family packages.

The attacker managed to engineer a path where their own CI pipeline stole its own publish token for them, at the exact moment it was created, by way of a cache that everyone in the chain implicitly trusted.

What the malware does

When anyone runs npm install , pnpm install or yarn install against any affected version, npm resolves the optionalDepedencies array where the attacker added a pointer to a specific commit in a GitHub fork which contains the malicious package entry and executes a router_init.js . The script does the following things -

1. Steals every credential it can find: It walks through all the usual places developer machines and CI runners keep secrets. Your ~/.npmrc, your GitHub tokens (env vars, gh CLI config, .git-credentials), your SSH private keys, your cloud runners.
2. Smuggles the stolen secrets out using Session messenger: Session is an encrypted messaging app, and the malware uses its file-upload servers as a dead drop. The traffic looks like normal Session traffic, and the contents are end-to-end encrypted so even your network monitoring can't see what's being exfiltrated. The only way to stop it at the network level is to block the Session domains outright.
3. Tries to spread: That's the worm part of the attack. One compromised maintainer becomes the next set of compromised packages, which compromises the next set of maintainers, and so on.

Who was affected

42 packages, 84 versions, published in two waves roughly 6 minutes apart between 19:20 and 19:26 UTC on 2026-05-11. Confirmed clean families include @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store, and the @tanstack/start meta-package (but not @tanstack/start-*). Anyone who installed an affected version on 2026-05-11 must treat the install host as potentially compromised.

What should you do

1. Check your lockfiles for @tanstack/* resolutions dated 2026-05-11. The IOC fingerprint is an optionalDependencies entry pointing to "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c" and a router_init.js file at the package root.
2. If you find a hit, rotate everything reachable from that install host. AWS, GCP, Kubernetes, Vault, GitHub, npm, and SSH credentials.
3. Pin to known-good versions. TanStack has deprecated all 84 affected versions and npm security pulled the tarballs.
4. Audit your own pull_request_target workflows. If any of them checks out a fork's code and runs it, you have the same primitive sitting in your CI.

Lessons learnt

pull_request_target is a bad security practice and has been documented for over three years. TanStack had it in production, and so does a meaningful fraction of every popular OSS repo on GitHub right now. Worth running zizmor against your workflows this week.

Read the full postmortem here