TanStack Npm Supply-Chain Attack: 42 Packages Compromised with Valid SLSA Provenance

On May 11, 2026, attackers published 84 malicious versions across 42 official @tanstack npm packages — including @tanstack/react-router, which pulls more than 12.7 million weekly downloads — through TanStack’s own legitimate release pipeline. The malicious tarballs carried valid SLSA provenance, the cryptographic proof of origin that defenders rely on to confirm a package wasn’t tampered with.

This is the first documented case of malicious npm packages shipping with valid provenance attestation. The defenders’ trust signal worked perfectly. It just happened to be signing the attack.

The attack chain, briefly

Tanner Linsley and the TanStack team have published a detailed postmortem of how this unfolded, and it’s worth reading in full. The short version is that the attackers did not steal any credentials. There were no compromised maintainer accounts. There was no long-lived npm publish token to steal — TanStack had deliberately moved to OIDC trusted publishing, specifically to eliminate that class of attack. Every maintainer had 2FA enabled.

What the attackers did instead was chain three known GitHub Actions vulnerabilities into a single execution path. They created a fork named zblgg/configuration (deliberately obscured to evade fork-list searches), opened a pull request that triggered a pull_request_target workflow, used that workflow’s fork-trusted context to poison the GitHub Actions cache, then waited for legitimate maintainer PRs to merge — at which point the release workflow restored the poisoned cache and the attacker-controlled code extracted an OIDC token directly from the runner’s process memory. That token was used to publish 84 malicious package versions through the legitimate publishing path. The whole sequence took six minutes.

Wiz’s analysis of the incident attributes the campaign to a threat group called TeamPCP, the same operators behind the recent compromises of Trivy, Bitwarden CLI, Intercom, and others. The campaign extends well beyond TanStack: over 170 packages across npm and PyPI were hit on the same day, including UiPath, Mistral AI, Squawk, Guardrails AI, and the OpenSearch JavaScript client.

The dead-man’s switch

The payload itself is what’s keeping incident responders awake. The malware installs a persistent daemon called gh-token-monitor on the victim’s machine that polls GitHub roughly every minute, checking whether the stolen GitHub token has been revoked. The moment it sees a revocation, it triggers an rm -rf wiper across the user’s home directory.

This is a defender-punishing payload. The standard incident response playbook — see the compromise, revoke the tokens immediately — is now the trigger that destroys the developer’s machine. Wiz’s guidance is explicit: check for and remove the gh-token-monitor daemon antes revoking any tokens.

StepSecurity’s writeup details additional payload behaviour: the worm propagates by using stolen OIDC and npm tokens to publish malicious versions of any package the victim has write access to, it now targets password manager vaults including 1Password and Bitwarden, and it checks the system locale — playing an MP3 at full volume and deleting files on machines configured for Israel or Iran, while skipping Russian-locale systems entirely.

The initial wiper had a bug (missing --no-preserve-root, which causes rm -rf / to fail on modern Linux), but Wiz has since observed an updated payload with the bug resolved.

Why provenance failed

SLSA provenance is the cryptographic certificate, generated by Sigstore, that’s supposed to verify a package was built from a trusted source. Snyk’s breakdown makes the point clearly: provenance worked exactly as designed. It attested, truthfully, that these packages were built by TanStack’s release workflow running in TanStack’s repository. That attestation was correct. The problem is that “built by the legitimate workflow” stopped meaning “contains the code maintainers intended” the moment the workflow’s runtime was hijacked.

Any npm package using OIDC trusted publishing without strict branch and workflow pinning is vulnerable to this same class of attack. Provenance attestations remain necessary; they have stopped being sufficient.

What this means beyond JavaScript

The pattern here, in that attackers exploiting trust between systems rather than stealing credentials from people, is the same pattern we’ve seen across the most consequential supply-chain incidents of the past year. We wrote about it in our coverage of the Vercel breach, where an attacker walked into Vercel’s environment through an OAuth token an employee had granted to a consumer AI tool months earlier. Both incidents share the same characteristic: every individual step looked legitimate at the time it happened.

The earlier waves of the Shai-Hulud worm established the self-propagation mechanism through compromised maintainer credentials. This wave removes the need to compromise a maintainer at all. It is the natural evolution of the supply chain vulnerabilities that have driven 91% of organisations to experience a software supply-chain incident in the past year, and it should reframe how security teams think about CI/CD as part of their attack surface.

What to do right now

If your team installed any affected @tanstack version on May 11, the install host should be treated as compromised. Check for and remove the gh-token-monitor daemon first. Only then rotate npm tokens, GitHub PATs and OIDC trusts, AWS credentials (static keys and instance roles), Vault tokens, Kubernetes service account tokens, and SSH keys reachable from the install host. The full affected package list is in GHSA-g7cv-rxg3-hmpx.

More broadly, this is the moment to audit GitHub Actions workflows for pull_request_target patterns that execute fork code, pin third-party actions to commit SHAs rather than floating refs, and ensure trusted-publisher configurations specify both branch and workflow. Continuous monitoring of credential exposure on underground markets and Telegram channels provides the second line of defence, because the OIDC tokens stolen in this attack, and the secrets they unlocked, will show up there long before anyone notices the lateral movement they enabled.