TanStack reports npm supply-chain attack across 42 packages with credential-stealing payload

• tan_stack's security advisory said 42 @tanstack/* packages, 84 versions total, were compromised in two publish bursts between 19:20 and 19:30 UTC on May 11.
• According to tan_stack's advisory, the malicious versions exfiltrated AWS, GCP, Kubernetes, and Vault credentials, plus GitHub tokens, .npmrc contents, and SSH keys.
• The compromised manifests added an optionalDependencies entry for @tanstack/setup pointing at github:tanstack/router#79ac49ee..., and tan_stack's advisory said that git-resolved dependency ran a prepare script that launched router_init.js from the tarball root.
• tan_stack's GitHub advisory link and tan_stack's postmortem post said npm policy blocked unpublishing for most affected packages, so TanStack deprecated all 84 versions with a security warning while npm security worked to pull tarballs at the registry level.
• A widely shared screenshot from dabit3's dead-man's-switch post claimed the payload also installed a token monitor that could run rm -rf ~/. after a stolen GitHub token was revoked.

You can jump from TanStack's GitHub security advisory to the postmortem, then cross-check the package list and payload notes in Socket's technical breakdown. One of the stranger details came from dabit3's screenshot, which described a token monitor that polled GitHub every 60 seconds. Another useful wrinkle came from a repost of mitsuhiko's comment, which said the malicious publish used OIDC trusted publishing.

TanStack's first public advisory pinned the malicious publishes to roughly 19:20 and 19:26 UTC, with two bad versions per affected package.

The company said 42 packages were hit, 84 versions total, and told users who installed any @tanstack/* package during that 10-minute window to treat the host as potentially compromised. In tan_stack's GitHub advisory link, the team added that unpublish was blocked for most packages because of existing third-party dependents, which pushed the response toward deprecations and registry-level takedown work instead of a clean yank.

The fastest detection rule came directly from the advisory: compromised manifests contained an optionalDependencies block that pulled @tanstack/setup from a GitHub commit inside tanstack/router.

According to tan_stack's advisory, that dependency path ran a prepare script and executed router_init.js, a roughly 2.3 MB file smuggled into each tarball at the package root. Socket's write-up described the same campaign as part of the Mini Shai-Hulud supply-chain attack and published the full affected package and version list.

TanStack's own severity note was blunt. tan_stack's advisory said the payload targeted cloud credentials, GitHub tokens, .npmrc contents, and SSH keys, which makes this incident closer to a workstation and CI secret grab than a simple package defacement.

TanStack used three public surfaces in quick succession: the initial X advisory, a GitHub security advisory, and then a postmortem tied from the account a little over two hours after the first alert.

The response details were unusually specific for an active npm incident. tan_stack's advisory said the publish path was being shut down, all 84 malicious versions were being deprecated with a SECURITY warning, and npm security had been engaged to remove tarballs at the registry level. threepointone's repost of SocketSecurity added a broader ecosystem claim from Socket, which said it had found 121 more compromised npm artifacts across 84 package names, including 64 UiPath artifacts.

The nastiest detail in the evidence pool did not come from TanStack. It came from a screenshot amplified by dabit3's dead-man's-switch post.

The screenshot claimed the payload dropped ~/.local/bin/gh-token-monitor.sh and registered it as a Linux systemd user service or a macOS LaunchAgent named com.user.gh-token-monitor. It then polled api.github.com/user every 60 seconds and, on an HTTP 40x that suggested the stolen token had been revoked, ran rm -rf ~/..

That claim is attributed to the screenshot, not TanStack's advisory or postmortem. But it helps explain why the incident spread so fast through developer circles: the payload was being discussed ոչ only as credential theft, but as credential theft with host-destructive behavior attached.

One community detail surfaced after the first wave of incident posts: a repost of mitsuhiko's comment said the malicious release was published through OIDC trusted publishing.

That matters because it narrows one common early theory. The incident was not necessarily a plain leaked npm token story. If the attacker really shipped through trusted publishing, the compromise path sits further upstream, in the release workflow or identity chain that npm accepted as legitimate. TanStack's public posts in this evidence set do not spell out that root cause, so that part remained unresolved in the company's initial incident communications.