The attack came through legitimate channels — what developers should check after the TanStack, Nx Console and GitHub chain

The affected packages are 42 Router/Start packages, 84 versions, including @tanstack/react-router, @tanstack/react-start, @tanstack/router-core and @tanstack/history (full list in GitHub advisory GHSA-g7cv-rxg3-hmpx). TanStack says Query, Table, Form, Virtual and its other packages were not affected. Check not only your lockfile's current contents but its change history around May 11, 2026. The malicious versions were removed from npm within hours, so an install during that window may not show in today's lockfile. In CI, look for jobs that ran an install after 19:20 UTC on May 11.

Nx's postmortem shows how to check the installed version with code --list-extensions --show-versions (the extension ID contains angular-console). Only v18.95.0 was affected, and it was available on May 18 between 12:30 and 13:09 UTC. Nx asks that anyone who had Nx Console with auto-update enabled during that window treat the machine as compromised, whichever install figure turns out to be right. The postmortem also lists files and processes to look for (indicators of compromise); if you are affected, work through that list.

TanStack and Nx list the same targets: GitHub tokens, npm tokens, SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes, Vault tokens, and the contents of any .env file. Nx adds credentials that tools on the machine could have minted during the window (temporary cloud credentials, GitHub CLI tokens and so on), and recommends considering a full rebuild of the machine after rotation. For revocation order and how to handle resident malware, see the "if you suspect infection" section of Defending against npm supply-chain worms.

According to TanStack, the code looked for other packages the victim maintains and tried to republish them with the same injection. If you publish to npm, check your packages' version history for versions you did not publish since May 11.

According to Nx, the stolen credential was a GitHub CLI token. In that environment it was stored in a file on disk and readable by any process running as the user, and it was used against the GitHub API within 74 seconds. Run gh auth status to see where yours is stored; if it sits in a plain file, consider moving it to the OS keychain or to a password-manager integration that injects the credential only at run time. After the incident, Nx's policy now disallows direct use of the GitHub CLI on developer machines. For narrowing token lifetime and scope, see Defending against npm supply-chain worms.

According to Nx, the compromised contributor's project had minimum-release-age=10080 (7 days) in its .npmrc, but the project pinned pnpm 10.14, which does not support that setting and silently ignored it. Support starts with pnpm 10.16. The malicious version was only 77 minutes old at install time, so a working setting would have blocked it. Check the version pinned in the packageManager field of package.json, and have CI verify that it is new enough. The equivalent setting for npm is covered in Defending against npm supply-chain worms.

On May 26, GitHub announced that it is rotating keys, including the key that signs GitHub Enterprise Server update packages. Admins must rotate the GPG public keys in their instance; otherwise future upgrades fail with an error saying the file is not a valid GHES package. The instructions and the SHA256 digest of the helper script are in GitHub's post. GitHub also asks customers to download GHES updates only from the official source and to prepare to take security updates at an increased rate over the coming months. GitHub Enterprise Cloud customers need to take no action.

According to TanStack, a bundle-size workflow ran on pull_request_target and, inside it, checked out and built code from a fork's pull request. pull_request_target runs with the base repository's privileges, and TanStack notes that the approval gate for first-time contributors does not apply to this trigger. Keep it to tasks that never run outside code, such as labeling and commenting. After the incident, TanStack removed every use of pull_request_target from its CI.

According to TanStack, the GitHub Actions cache is shared per repository: pull_request_target runs and pushes to main use the same scope. Cache saves are also not blocked by setting the workflow's permissions: to read-only. As a result, the release workflow restored a cache written by a job that had run outside code. After the incident, TanStack disabled the package cache in its release pipeline and purged all caches. Not restoring caches in workflows that publish is the simplest line to draw.

TanStack's release workflow held id-token: write for npm trusted publishing (OIDC). According to the postmortem, the malicious publish did not come from the workflow's defined publish step; code running in another stage of the same run extracted a token and published directly. TanStack's own lesson is that a trusted-publisher binding has no per-publish review. Split publishing into its own job, separate from build and test, give only that job the permission, and put it behind a GitHub environment with required reviewers. After the incident, Nx made approval by someone other than the person who triggered the run mandatory for publishing.

After the incident, both TanStack and Nx pinned every action reference to a commit SHA instead of a tag or branch. TanStack describes floating references as "standing supply-chain risk independent of this incident".

Nx caught the tampered release through the routine notification email the extension marketplace sends on every upload. A maintainer who was not expecting a release recognized it as anomalous and unpublished within about 11 minutes. The second distribution channel had no such notification, and removal there took about 36 minutes. Meanwhile, activity with the stolen token, such as deleting workflow runs, sat in the audit log for a week unnoticed. Check that publish notifications reach someone on the team and that someone watches the audit log for deleted workflow runs.