84 Malicious TanStack Packages Hit npm Via GitHub Actions Exploit Chain

What Happened

On May 11, 2026, an attacker executed a multi-stage supply-chain attack against TanStack — the widely-used open-source project behind TanStack Query, TanStack Router, TanStack Table, and dozens of other packages that collectively see millions of weekly npm downloads. The attacker chained three distinct vulnerabilities — a pull_request_target Pwn Request, GitHub Actions cache poisoning across the fork-to-base trust boundary, and OIDC token extraction from runner memory — to publish 84 malicious package versions across 42 @tanstack/* packages on npm.

The attack vector was sophisticated but not novel in its individual components. The `pull_request_target` event in GitHub Actions has been a known footgun since 2020: it runs workflow code from the *base* branch but in the context of the *pull request*, which means a forked PR can trigger workflows with write access to the target repository. What made this attack notable was the chaining. The attacker poisoned the GitHub Actions cache — exploiting the shared object storage between forks and base repositories — to inject code that would execute during legitimate CI runs. From there, they extracted OIDC tokens from runner memory, which gave them the ability to publish packages via npm's Trusted Publishing mechanism.

The compromise also extended beyond TanStack. As community member varunsharma07 flagged, the @mistralai/mistralai npm package was compromised as part of the same worm-like propagation, with the malicious version eventually pulled from the registry.

The Payload: A Dead-Man's Switch

The malicious packages didn't just exfiltrate data — they established persistence. On installation, the payload dropped a dead-man's switch at `~/.local/bin/gh-token-monitor.sh` as a systemd user service on Linux and a LaunchAgent (`com.user.gh-token-monitor`) on macOS. This service polls `api.github.com/user` with the stolen GitHub token at regular intervals.

This is a critical detail for remediation. As HN commenter cube00 warned: simply revoking tokens isn't sufficient if the monitoring service is already installed. The persistence mechanism means the attacker can detect when their stolen credentials stop working and potentially escalate before you've finished cleaning up. Any remediation plan needs to include checking for and removing these services *before* revoking tokens — or at minimum, doing both simultaneously.

Why npm Made It Worse

The TanStack team's postmortem reveals a painful operational reality: npm's "no unpublish if dependents exist" policy meant the team couldn't remove the malicious packages themselves. They had to file a request with npm's security team and wait for server-side tarball removal. During those hours of delay, every `npm install` that resolved to an affected version was pulling down the compromised code.

This is a policy designed to prevent the left-pad scenario — where unpublishing a popular package breaks half the internet. But as commenter ezekg pointed out, it creates a perverse incentive structure during active supply-chain compromises: the more popular a package is (and thus the more critical it is to remove a malicious version), the harder it is to remove. The npm team has the ability to act, but the human-in-the-loop delay during an active incident is measured in hours, not minutes.

For context, pnpm users had a partial mitigation here. As chrisweekly noted, pnpm's stricter handling of postinstall scripts and its content-addressable store model reduce (but don't eliminate) the attack surface. The broader point stands: the npm ecosystem's trust model has a structural gap between "package published" and "package verified safe."

The Trusted Publishing Paradox

Perhaps the most uncomfortable takeaway is what this attack means for OIDC-based Trusted Publishing — the mechanism that was supposed to make npm publishing safer by eliminating long-lived tokens. Trusted Publishing worked exactly as designed, and the attacker used it to publish malicious packages. As jonchurch_ observed, TP is not meant to guarantee against an attacker who is already inside your CI pipeline. It prevents stolen npm tokens from being used *outside* CI; it says nothing about the integrity of what happens *inside* CI.

This isn't a failure of Trusted Publishing — it's a failure to understand its threat model. TP solves the "developer laptop compromised, npm token stolen" scenario. It does not solve the "CI pipeline compromised" scenario. The TanStack attack lived entirely within the CI trust boundary, which means the OIDC tokens it extracted were legitimate, the publish operations were authorized, and npm had no signal that anything was wrong.

The implication for maintainers is stark: Trusted Publishing is a necessary but insufficient security measure. You also need to harden your CI pipeline itself — which means auditing `pull_request_target` usage, understanding cache trust boundaries, limiting OIDC token permissions, and treating your GitHub Actions configuration as a security-critical attack surface.

What This Means for Your Stack

Immediate actions: Check your lockfiles. If any `@tanstack/*` dependency shows a version published on May 11, 2026, pin to the last known-good version from before that date. Search your systems for `gh-token-monitor.sh` (Linux) or the `com.user.gh-token-monitor` LaunchAgent (macOS). If found, remove the persistence mechanism and rotate all GitHub tokens, npm tokens, and any other credentials accessible from that machine.

CI hardening: Audit every workflow that uses `pull_request_target` — if you don't understand exactly why it's there and what permissions it grants, replace it with `pull_request`. Review your GitHub Actions cache usage and consider whether fork PRs should be able to influence cache contents. If you use OIDC-based publishing, scope the tokens as narrowly as possible and add manual approval gates for publish steps.

Dependency management: This is the third major npm supply-chain incident in 18 months, and the attack sophistication is increasing. If you're not already using a lockfile, start. If you're not pinning exact versions in CI, start. If you're not running `npm audit` in CI, start. Consider tools like Socket.dev or Snyk that analyze package behavior rather than just known vulnerabilities. And if you're still running `npm install` with postinstall scripts enabled by default, evaluate whether `--ignore-scripts` with explicit allowlists is feasible for your workflow.

Looking Ahead

The TanStack compromise marks an inflection point in supply-chain attack sophistication. The individual techniques — Pwn Requests, cache poisoning, OIDC extraction — have all been documented in security research. What's new is seeing them chained together against a high-profile target with surgical precision. GitHub's shared object storage model for forks, npm's unpublish restrictions, and the gap between Trusted Publishing's promise and its actual threat model all contributed to the blast radius. Expect GitHub to face pressure to rearchitect the fork trust boundary, npm to revisit emergency unpublish policies, and the ecosystem to reckon with the fact that CI pipelines are now the primary attack surface for package registries — not developer laptops, not stolen tokens, but the automation we built to make publishing safer.