- The TanStack npm supply chain attack compromised 42 packages in just six minutes on May 11, 2026.
- This npm supply chain attack is the first known case where malicious packages carried valid, unforged SLSA provenance attestations.
- Attackers used a GitHub Actions cache-poisoning technique to inject malicious code before the trusted publish step ran.
- Secondary victims included packages from Mistral AI, UiPath, and aviation-related namespaces, showing how fast these payloads self-propagate.
- The TanStack npm supply chain attack compromised 42 packages in just six minutes on May 11, 2026.
- This npm supply chain attack is the first known case where malicious packages carried valid, unforged SLSA provenance attestations.
- Attackers used a GitHub Actions cache-poisoning technique to inject malicious code before the trusted publish step ran.
- Secondary victims included packages from Mistral AI, UiPath, and aviation-related namespaces, showing how fast these payloads self-propagate.
The TanStack npm Supply Chain Attack, Explained
At 19:20 UTC on May 11, 2026, the npm registry started receiving something it had no reason to reject: new versions of TanStack packages, signed correctly, with valid provenance, shipping from the right repository. Six minutes later — 19:26 UTC — 84 malicious versions across 42 packages had landed. The npm supply chain attack was already complete before most of TanStack’s maintainers had any idea it was happening.
TanStack has since published a detailed postmortem covering the full attack chain. What emerges from that document is a story about sophistication, not brute force. The attacker — operating under accounts identified as zblgg and voicproducoes — didn’t steal anyone’s password or phish a maintainer’s session. They found a structural weakness in how GitHub Actions workflows share trust and data, and they walked through it methodically.
Threat intelligence firm Wiz has attributed the campaign — which it’s calling “Mini Shai-Hulud” internally — to a group called TeamPCP, previously linked to supply chain intrusions targeting SAP, Checkmarx, and Trivy. This wasn’t a random opportunist. It was a practised team running a repeatable playbook against open-source infrastructure.
Three Attack Primitives, Chained Together
Most supply chain incidents you read about come down to one thing: stolen credentials. Someone’s npm token gets compromised, a bad package goes out, the maintainer rotates their token, and everyone moves on. The TanStack npm supply chain attack is different because the attacker chained three distinct techniques — and each one handed off to the next.
Step One: The Pwn Request
The entry point was a GitHub Actions anti-pattern that has a name in the security community: a “Pwn Request.” It exploits workflows that use pull_request_target as their trigger.
Here’s the problem with that trigger. When a pull request comes in from a fork, pull_request_target runs the workflow in the context of the base repository — meaning it has access to the base repo’s secrets. That’s by design; it lets maintainers do things like post automated comments on external PRs without handing secrets to the fork’s code. But if that same workflow also checks out and executes the fork’s code, you’ve just given untrusted code access to trusted secrets. That’s the Pwn Request.
TanStack’s bundle-size.yml workflow had exactly this configuration. The attacker opened a pull request from a fork. The workflow executed the fork’s code with base repository privileges. The door was open. This single misconfiguration was enough to initiate a full npm supply chain attack.
Step Two: Cache Poisoning
Rather than immediately stealing secrets, the attacker did something more patient. Their malicious fork code wrote a 1.1 GB poisoned entry into the pnpm package store cache, using the exact cache key that TanStack’s legitimate release.yml workflow would later restore.
This is the trust-boundary crossing that makes this npm supply chain attack instructive. The bundle-size workflow — lower trust, triggered by pull requests — and the release workflow — higher trust, triggered by maintainer merges — shared a cache key namespace. There was no wall between them. The attacker wrote to cache from the low-trust context. Eight hours later, the high-trust release workflow pulled that cache entry and treated it as clean.
Eight hours. The poisoned cache sat there undetected, waiting.
Step Three: OIDC Token Extraction from Memory
This is the part that the broader ecosystem really needs to sit with. GitHub Actions supports OIDC-based publishing, which was supposed to eliminate the risk of long-lived npm tokens sitting in repository secrets. The workflow requests a short-lived token at publish time; npm accepts it. No stored credentials to steal.
Except the attacker’s payload included binaries that read /proc/<pid>/mem on the GitHub Actions runner. The GitHub Actions agent holds the OIDC token in memory while the job runs. The malicious code extracted that token directly from process memory and used it to authenticate npm publishes — completely bypassing the actual publish step in the release workflow.
The result: packages that looked, to every automated system, like they came from TanStack’s legitimate pipeline. Because technically, they did. This memory-extraction technique is now a documented vector in any npm supply chain attack targeting OIDC-based workflows.
Why SLSA Provenance Didn’t — and Couldn’t — Catch This npm Supply Chain Attack
This is the part that should reshape how the industry talks about supply chain trust.
SLSA (Supply chain Levels for Software Artifacts) provenance is one of the most significant investments the open-source ecosystem has made in package security over the past few years. The promise is real: a package with SLSA provenance carries a cryptographic attestation proving it was built from a specific source commit in a specific workflow. Consumers can verify this. It’s a meaningful signal.
The TanStack incident is the first documented case of an npm supply chain attack where malicious packages carried valid SLSA provenance attestations that the attacker did not forge. Sigstore verified the build correctly. The provenance was real. The pipeline ran. The code running through that pipeline just wasn’t safe.
This exposes a conceptual gap that the ecosystem has largely papered over. SLSA provenance answers the question: “Did this package build the way the maintainer intended?” It does not answer: “Was the build environment clean before the build started?” Those are different questions. The TanStack npm supply chain attack exploited the gap between them.
That doesn’t make SLSA worthless — a package with no provenance is still less trustworthy than one with provenance. But it does mean provenance is a necessary condition, not a sufficient one. Treating it as a complete solution is a mistake the ecosystem can no longer afford to make.
The Payload: What Got Installed on Victim Machines
For anyone who installed an affected TanStack Router or Start package during the 4.5-hour window between the initial publish and npm’s removal of the tarballs — from roughly 19:20 to 23:55 UTC — the payload was a 2.3 MB obfuscated file called router_init.js.
It was comprehensive in the worst possible way. The payload harvested GitHub tokens, AWS keys, HashiCorp Vault tokens, Kubernetes service account credentials, SSH keys, and GCP credentials. Exfiltration ran over the Session/Oxen P2P messenger network — a deliberate choice that makes traffic harder to detect or block with standard network monitoring. Any stolen publish-capable tokens were immediately used to republish the payload to every other package the victim had write access to. That’s how this npm supply chain attack spread beyond TanStack’s own scope.
Secondary victims confirmed in the postmortem include @mistralai/mistralai, more than 40 @uipath packages, and 19 packages in aviation-related namespaces. Persistence mechanisms were installed via .claude/settings.json hooks, VS Code task injection, and a systemd monitoring service. And if a stolen GitHub token was later revoked, the payload wiped the victim’s home directory.
That last detail is not just destructive — it’s a signal. This is operational tradecraft designed to cover tracks and punish incident response.
How It Was Caught — and What That Tells You
An external researcher named ashishkurmi from StepSecurity spotted the anomaly within minutes of the first publish — an unusual optionalDependencies entry in the package metadata pointing to a GitHub fork. No internal alerting triggered on TanStack’s side. The malicious versions were deprecated 1 hour 43 minutes after the first publish, and npm pulled the tarballs over a window ending at 23:55 UTC.
The detection was external, accidental in the sense that it depended on one person’s vigilance, and it still took nearly two hours to act on. That’s a gap most production environments can’t absorb comfortably. In any npm supply chain attack of this scale, a two-hour detection lag is enough time for the payload to propagate far beyond the original target.
What Your Project Should Change This Week After This npm Supply Chain Attack
TanStack’s postmortem is worth reading in full, but the actionable changes break down into a few categories that apply to essentially any project using GitHub Actions and publishing to npm.
- Audit every workflow that uses pull_request_target. If it also checks out fork code and executes it, you have a Pwn Request waiting to happen. Either remove the checkout, scope the permissions tightly, or switch to a safer trigger pattern.
- Isolate cache key namespaces between trust levels. Low-trust workflows (PR-triggered) and high-trust workflows (release-triggered) should never share a writable cache namespace. If they do, assume the cache can be poisoned — as this npm supply chain attack demonstrated.
- Don’t treat OIDC-based publishing as credential theft-proof. The TanStack incident shows that OIDC tokens can be extracted from runner memory if an attacker gets code running in the pipeline earlier in the job. Shorter token lifetimes help but don’t eliminate this risk.
- Monitor outbound traffic from your CI runners. Exfiltration over P2P networks is specifically designed to evade standard monitoring. Consider egress filtering and anomaly detection at the runner level, not just at the application level.
- Verify optionalDependencies in dependency updates. The anomaly that ashishkurmi caught was visible in the package metadata. Automated checks on dependency graph changes — especially forks appearing as optional deps — would have flagged this npm supply chain attack earlier.
- Don’t rely solely on SLSA provenance as a trust signal. It tells you the build ran correctly. It doesn’t tell you the build environment was clean. Layer additional checks: dependency pinning, reproducible builds, and runtime integrity verification.
The broader implication here is uncomfortable. The security tools the ecosystem has been building — OIDC publishing, SLSA provenance, Sigstore attestations — are genuinely valuable. But they were designed with a threat model in mind that assumes the pipeline itself is trustworthy. TeamPCP, and groups like them, are specifically targeting that assumption. Every successful npm supply chain attack they execute is a demonstration that this assumption cannot hold. The answer isn’t to abandon these tools. It’s to build the next layer of defence that assumes the pipeline can be compromised too — and asks what evidence you’d need to detect that when it happens.
