If you install any tanstack package you might be affected. Thats 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.
...ok... I get it, but...
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.
...now the 1 million dollars question...
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.
you can run this and check all your repositories locally, imagine they are under the path dev, you run:
find ~/dev -path "*/node_modules/@tanstack/*/package.json" \
-newermt "2026-05-11 00:00:00" ! -newermt "2026-05-12 00:00:00" \
-exec echo "⚠️ check this: {}" \;
changed based on your path...
Rotate immediately:
- AWS credentials
- GitHub personal access tokens
- npm tokens
- SSH private keys
- Any secrets that lived in environment variables on that machine
...and...
--
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.
Top comments (1)
This attack is honestly a reminder that modern software supply chains are starting to look less like dependency trees and more like biological ecosystems 😅.
The scary part isn’t just the malware itself — it’s how elegantly the attackers abused trusted CI/CD assumptions instead of brute-forcing credentials.
The pull_request_target + cache poisoning + OIDC chain is a masterclass in why “secure by default” still isn’t default in many workflows.
What really stood out to me is the delayed detonation strategy; the patience behind this attack makes it feel more like an APT operation than a typical npm incident.
Also, the phrase “npm install” officially carries emotional damage now 😂.
The practical mitigation advice here is excellent too — especially isolated dev environments and restricting postinstall behavior.
Great breakdown of a very serious ecosystem-level problem in a way developers can actually understand and act on.