How it unfolded

1. 1

   A pull request opens the door

   An attacker opens an ordinary-looking PR against a workflow triggered on pull_request_target that checks out the PR's own head commit. That trigger runs with the base repository's secrets and cache access, even though the code being executed is the attacker's.

2. 2

   The shared build cache gets poisoned

   During that run, the attacker's code writes a tampered dependency store into GitHub Actions' cache under the same key a legitimate release build would use — cache keys are derived from the lockfile hash and scoped to the whole repository, not to the branch or workflow that wrote them.

3. 3

   A real release restores the poisoned entry

   Days or weeks later, a maintainer pushes to main and the publish workflow runs. It restores the cache entry with the matching key — the poisoned one — and installs from it, with no indication anything is wrong.

4. 4

   The publishing token is extracted from memory

   The tampered install code executes inside the trusted release job and dumps runtime memory, recovering the OIDC token the workflow had just obtained to authenticate to the npm registry.

5. 5

   84 malicious versions ship before detection

   Using the stolen token, the attacker publishes 84 tampered versions across 42 @tanstack/* packages — including Query, Router, and Form, each with millions of weekly downloads — before the versions are caught and yanked.