For two years the advice on npm security has been the same: move to trusted publishing, drop long-lived tokens, attach provenance. TanStack had done all of that. On May 11, 2026, attackers published malicious versions of its packages anyway.

How the attack worked

TanStack’s post-mortem lays out the chain. The attacker forked the TanStack/router repository on May 10 and used it against three weaknesses that are each common on their own:

  1. A pull_request_target workflow that ran code from the fork with the base repository’s privileges.
  2. Cache poisoning. That code wrote a tampered pnpm store into the GitHub Actions cache, which the real release workflow later restored.
  3. OIDC token theft. During the release run, the poisoned dependencies read a short-lived OIDC token from runner memory and used it to publish directly to npm.

Between 19:20 and 19:26 UTC, 84 malicious versions of 42 @tanstack/* packages went out. Because they came out of TanStack’s genuine pipeline, they carried valid SLSA provenance. StepSecurity, quoted by The Hacker News, called it the first npm worm to produce validly attested malicious packages.

TanStack stresses that no npm tokens were stolen and its publish workflow was not itself modified. The attackers didn’t need to.

What the payload did

The researchers who analysed it describe a credential stealer with self-propagation:

  • It collected cloud, Kubernetes, Vault, npm, GitHub and SSH credentials and sent them out over the Session/Oxen network.
  • It republished other packages the victim maintained, which is what made it a worm.
  • It installed persistence in .claude/ and .vscode/ folders and a fake gh-token-monitor service.
  • It carried a dead-man’s switch: if its stolen npm token was revoked, it ran rm -rf ~/.

That last detail changes incident response. Revoking credentials first, the usual instinct, could wipe the machine you need to investigate. Isolate and image first, then rotate.

The response

TanStack deprecated the first malicious versions 59 minutes after they appeared and the last batch by 21:03 UTC. npm removed the tarballs between 22:13 and 23:55 UTC. The project gave the all-clear on May 15.

The wider campaign reached well beyond TanStack, including the mistralai PyPI package (version 2.4.6), Guardrails AI, UiPath and OpenSearch. Vendor counts differ: OX Security, via The Hacker News, reported more than 170 packages with around 518 million cumulative downloads, while Orca counted 373 package versions across 169 npm names plus two on PyPI. The Hacker News and Orca link it to a group tracked as TeamPCP; TanStack itself names no attacker.

Why it matters

  • Provenance tells you where a package was built, not whether the build was safe. A compromised pipeline produces perfectly attested malware.
  • Audit pull_request_target. Any workflow that runs fork code with write permissions or access to shared caches is a release-pipeline risk.
  • Isolate caches between untrusted and release jobs. The Actions cache was the bridge here.

If you installed any @tanstack/* version published on May 11, follow the advisory: treat the machine as compromised, image it, then rotate every credential it could reach from a clean device.

Sources

  1. TanStack: npm supply chain compromise post-mortem (May 11, updated May 15, 2026)
  2. The Hacker News: Mini Shai-Hulud worm compromises TanStack and other packages (May 12, 2026)
  3. Orca Security: TanStack npm supply chain worm (May 12, 2026)

We link every claim to the reporting or official statement it comes from. Where a detail rests on one outlet’s reporting, we say so. Spotted an error? Reply to any newsletter and we’ll correct it.