If you install any tanstack package you might be affected. That it, on May 11, 2026, one of the most sophisticated npm supply chain attacks ever seen hit the JavaScript ecosystem, and it's still spreading.
This is my attempt to explain it simply, because the technical details are buried in postmortems and most developers I know haven't fully digested what this means for them.
What happened
The attackers compromised 42 TanStack packages, publishing 84 malicious versions in a 6-minute window. TanStack is widely used, Query, Router, Start, so the blast radius was insane.
But here's what makes this different from a typical "someone hacked a maintainer's account" story: no passwords were stolen. The attackers never needed them.
The clever part: the attack chain
The attacker opened a pull request to TanStack's GitHub repo. Looks innocent. But they exploited three things in sequence:
1. A dangerous GitHub Actions trigger
The workflow used pull_request_target instead of pull_request. The difference sounds minor but it's huge. pull_request_target runs in the context of the base repository, meaning it has access to secrets and can write to the Actions cache — even from a forked PR.
2. Cache poisoning
The malicious PR code ran during CI and wrote a poisoned 1.1 GB cache entry keyed to match what the release workflow would look up on the next push to main. Then the attacker quietly reverted the PR to a no-op and closed it. The cache stayed poisoned.
3. OIDC token theft
When a legitimate maintainer merged an unrelated PR days later, the release workflow started, restored the poisoned cache, and the malware ran inside the trusted CI context. It then minted a short-lived OIDC token (the kind used for "Trusted Publishing" on npm) and published the malicious versions directly — all while the legitimate workflow showed a failure status.
No npm credentials. No compromised passwords. Just a poisoned cache waiting for the right moment.
What the malware does
Once installed via npm install, it:
- Harvests AWS credentials, GitHub tokens, npm tokens, SSH keys, Kubernetes service account tokens
- Exfiltrates everything over an end-to-end encrypted channel (Session messenger's network), so you can't even block it by IP easily
- Self-propagates: looks up every package you maintain on npm and republishes them with the same payload This is a worm. It uses your own credentials to infect your own packages and spread to your users.
Are you affected?
Check if you installed or updated any @tanstack/* packages on the evening of May 11, 2026 (UTC). If yes, assume the machine that ran npm install is compromised.
Rotate immediately:
- AWS credentials
- GitHub personal access tokens
- npm tokens
- SSH private keys
- Any secrets that lived in environment variables on that machine ## How to protect yourself going forward
A few practical things you can actually do:
Don't develop on your host OS. Use Docker dev containers or VMs. If a postinstall script runs malware, it should be contained — not running as you on your machine with access to ~/.ssh and ~/.aws.
Don't store secrets in .env files. Use a proper secrets manager — Doppler, Infisical, AWS SSO. Your credentials shouldn't be sitting in plaintext files reachable by any package lifecycle script.
Configure your package manager to be defensive. Tools like pnpm and Bun let you disable postInstall scripts by default and require opt-in per package. Some support a minimum package age policy (don't install anything published less than 24 hours ago) — which alone would have protected against this attack.
If you maintain npm packages, audit your GitHub Actions workflows right now. If you use pull_request_target, understand exactly what it can access. Lock down cache permissions. Restrict id-token: write only to the specific job that needs it.
The frequency of these attacks is increasing. The sophistication too. This one had a 8-hour delay between poisoning the cache and detonating — patient, precise, automated.
The ecosystem isn't going to fix this overnight. But you can make your own environment significantly harder to compromise.
Stay skeptical of npm install now.