TanStack npm Supply Chain Attack: GitHub Actions OIDC Token Hijack Used to Publish 84 Malicious Package Versions

Attackers published 84 malicious versions across 42 @tanstack/* packages to the npm registry on 11 May, exploiting a chain of GitHub Actions misconfigurations in the TanStack project to operate under the trusted identity of one of the React ecosystem’s most widely used package families. The attack, assigned CVE-2026-45321 (CVSS 9.6), demonstrates the compounding risk when CI/CD automation is granted broad registry publish permissions without strict workflow isolation.

What Happened

Between 19:20 and 19:26 UTC on 11 May, an attacker published two malicious versions of each affected package in quick succession. The packages contained credential-stealing malware that executed on install via a postinstall lifecycle hook, exfiltrating developer environment variables, SSH keys, and npm access tokens to an attacker-controlled endpoint.

The attack chained three distinct techniques:

1. Pwn Request misconfiguration — TanStack’s CI used pull_request_target triggers, which execute in the context of the base repository — with full access to secrets — even when the pull request originates from a fork. An attacker-controlled fork submitted a crafted pull request that modified the workflow to capture the OIDC token at runtime.
2. GitHub Actions cache poisoning — The attack exploited the permeable boundary between fork and base repository caches, allowing the malicious workflow to seed a poisoned dependency cache accessible to legitimate base-branch runs.
3. Runtime OIDC token extraction — By executing within the base repository context, the malicious workflow extracted the GitHub OIDC token used to authenticate against npm’s trusted publisher feature, then immediately published the malicious packages using those credentials.

npm revoked the malicious versions within approximately 90 minutes of the first publication, and TanStack issued a security advisory confirming the incident and the safe package versions.

Affected Packages

The 42 affected packages cover the core TanStack ecosystem including @tanstack/react-router, @tanstack/react-query, @tanstack/react-table, @tanstack/react-form, and related adapter packages. Developers who ran npm install or npm ci against an affected version in the six-minute publication window may have been exposed.

Why It Matters

TanStack packages collectively exceed 100 million weekly downloads. Even a six-minute poisoning window represents meaningful exposure when npm install pipelines run continuously across CI/CD systems globally. The attack required no compromise of TanStack maintainer credentials — it exploited automation trust, not human credential theft.

The OIDC trusted publisher model — introduced specifically to eliminate long-lived npm tokens — was circumvented at the CI configuration layer rather than the authentication layer. This is structurally significant: token-based authentication hardening does not protect against workflow misconfigurations that allow untrusted code to execute in trusted contexts. The security control that was supposed to eliminate supply chain risk created a different attack surface.

Recommended Actions

• Audit your lockfile: Check node_modules and package-lock.json for @tanstack/* versions published on 2026-05-11 between 19:20 and 19:26 UTC. Any match indicates potential code execution during install.
• If exposed: Rotate all environment variables, SSH keys, and npm tokens present in the affected build environment. Treat the build machine as potentially compromised.
• CI/CD hardening: Replace pull_request_target triggers that run on fork PRs with pull_request triggers, which execute with read-only tokens and cannot access base repository secrets.
• Cache isolation: Configure GitHub Actions cache keys to include branch context and restrict cross-branch cache reads for workflows that handle secrets or publish to registries.
• Trusted publisher review: Audit which packages in your dependency tree use npm’s OIDC trusted publisher feature and validate their CI configurations are not vulnerable to Pwn Request attacks. This is distinct from auditing the packages themselves — it requires reviewing the upstream CI pipeline configuration.