TanStack npm Packages Hit by Supply Chain Attack Targeting CI Credentials

TanStack has confirmed a major npm supply chain attack that pushed malicious versions of 42 packages under the @tanstack namespace. In total, 84 compromised package versions were published before the project and npm security teams began removing or deprecating the affected releases.

The attack targeted developer and CI environments, not end users directly. The malicious payload was designed to steal credentials from systems that installed the compromised package versions, including GitHub tokens, cloud credentials, Kubernetes service account tokens, Vault tokens, npm configuration files, and SSH private keys.

The incident matters because TanStack packages are widely used across the JavaScript ecosystem. Many projects consume them directly, while others receive them through dependency chains. Any developer or CI runner that installed an affected version on May 11, 2026, should treat the host as potentially compromised.

What happened in the TanStack npm attack

The attack began with a malicious pull request from a fork of the TanStack router repository. The pull request did not need to be merged to cause damage. Instead, it triggered GitHub Actions workflows that used the pull_request_target event and checked out attacker-controlled code.

That code poisoned the GitHub Actions cache used later by TanStack’s release pipeline. When maintainers merged unrelated legitimate changes, the release workflow restored the poisoned cache. The malware then ran during the release job and extracted an OIDC token from the GitHub Actions runner process.

That token allowed the attacker to publish malicious packages through TanStack’s legitimate npm trusted-publisher setup. TanStack says no maintainer was phished, no maintainer password leaked, and no npm token was stolen.

Incident detail	Confirmed information
Affected namespace	@tanstack
Affected packages	42 packages
Affected versions	84 malicious versions
First publish wave	May 11, 2026, around 19:20 UTC
Second publish wave	May 11, 2026, around 19:26 UTC
Main target	Developer machines and CI/CD runners
Main risk	Credential theft and package self-propagation

The malware targeted GitHub Actions and cloud secrets

The malicious payload focused on secrets commonly found in developer environments. TanStack’s postmortem says it harvested credentials from AWS, Google Cloud, Kubernetes, HashiCorp Vault, npm configuration files, GitHub environments, the GitHub CLI, Git credentials, and SSH private keys.

The malware also had self-propagation behavior. After stealing credentials, it could enumerate npm packages controlled by the victim and republish infected versions using the same injection method.

This makes the incident more dangerous than a normal package compromise. A single infected CI runner could expose credentials and help the malware spread to other packages maintained by the same account or organization.

How the malicious package install worked

Security researchers found that compromised packages included a large obfuscated file named router_init.js. The payload used heavy JavaScript obfuscation and lifecycle execution techniques to run during package installation.

The GitHub advisory explains that affected packages used an optionalDependencies entry pointing to a suspicious orphan commit. That commit installed dependencies, ran a prepare lifecycle script, and then executed tanstack_runner.js, which launched router_init.js from the host package tarball.

The lifecycle script ended with a forced failure, which caused npm to discard the optional dependency. That behavior made the malicious component harder to spot because it could run without leaving a normal dependency entry behind in node_modules.

• Compromised packages contained router_init.js.
• The payload used obfuscation to hide its behavior.
• The install chain used an optional dependency tied to an orphan GitHub commit.
• The prepare script executed malicious code during installation.
• The optional dependency failed after execution, reducing visible traces.

Why trusted publishing did not stop the attack

TanStack used npm trusted publishing, OIDC, provenance, SLSA, and two-factor authentication. Those controls still matter, but this incident shows they cannot protect a release pipeline if attacker code runs inside the trusted workflow itself.

The malicious packages were published through the project’s own release pipeline identity. To npm, the publish event came from a trusted route. The problem was that the CI environment had already been poisoned before the publish step.

TanStack called the workflow shape the core failure. The attacker did not need to steal a permanent npm token because the release job created a short-lived token during the workflow, and the malware extracted it at runtime.

TanStack has deprecated affected versions

TanStack says it scanned all 295 @tanstack packages and confirmed the scope as 42 affected packages and 84 affected versions. The project began deprecating all affected versions with security warnings and worked with npm security to remove malicious tarballs where policy allowed.

The project also prepared clean follow-up releases. Developers should update to patched versions listed in the GitHub advisory and reinstall dependencies from a clean lockfile.

Teams should not simply bump package versions on a potentially compromised CI runner. If the malicious payload executed, the machine or runner should be isolated, rebuilt, and treated as a credential exposure event.

Risk area	Recommended response
Developer workstation	Check lockfiles and node_modules for affected versions, then reinstall from clean sources.
CI/CD runner	Isolate and rebuild the runner if a compromised version was installed.
GitHub tokens	Rotate exposed tokens and review repository activity.
Cloud credentials	Rotate AWS, GCP, Kubernetes, and Vault credentials that may have been accessible.
SSH keys	Replace exposed private keys and review login history.
npm access	Review package publish history and remove unexpected maintainers or tokens.

What developers should check now

Developers should review package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lock, and installed node_modules entries for affected @tanstack package versions. They should also search for suspicious filenames connected to this campaign, including router_init.js, router_runtime.js, tanstack_runner.js, and setup.mjs.

If a compromised version was installed locally or in CI, teams should assume that secrets available to that environment may have been exposed. That includes environment variables, cloud metadata credentials, GitHub tokens, npm credentials, SSH keys, and service account files.

After rotating credentials, teams should review cloud audit logs, GitHub Actions logs, npm publish history, repository events, and outbound network activity around the installation window.

1. Identify whether any affected @tanstack package version was installed.
2. Isolate affected workstations or CI runners.
3. Rebuild CI runners from a clean image.
4. Rotate GitHub, npm, cloud, Kubernetes, Vault, and SSH credentials.
5. Audit package publish history for unexpected releases.
6. Review cloud and repository logs for suspicious activity.
7. Update to clean TanStack releases.
8. Reinstall dependencies from a clean lockfile.

TanStack hardens GitHub Actions after the compromise

TanStack has already removed GitHub Actions caches from affected workflows and disabled the pnpm cache in the release pipeline. The project also pinned every GitHub Action across the organization to a commit SHA and removed pull_request_target usage from its CI workflows.

The maintainers also enforced non-SMS two-factor authentication across npm and GitHub. TanStack says more workflow hardening work is still underway, including stricter GitHub Actions scanning and tighter controls around repository workflow files.

The incident highlights a wider software supply chain problem. Provenance and trusted publishing can prove where a package came from, but they cannot prove the workflow was safe if attacker code already executed inside it.

Why this attack matters beyond TanStack

Security firms have connected the TanStack compromise to the Mini Shai-Hulud campaign, a newer wave of self-spreading package malware. The campaign focuses on stealing CI/CD secrets, spreading through package maintainers, and abusing trusted development infrastructure.

That makes the attack relevant to every open-source project using automated publishing. CI workflows need to treat cache access, pull request events, install scripts, OIDC permissions, and release jobs as high-value attack surfaces.

For organizations that depend on npm packages, the takeaway is simple. Dependency updates must be paired with secret exposure checks, CI hardening, and lockfile review. A clean package version fixes future installs, but it does not undo credentials stolen during a malicious install.

FAQ