Mini Shai-Hulud: 84 Malicious TanStack Packages Signed with Valid SLSA Level 3 Attestations

On May 11, 2026, the TeamPCP threat group compromised TanStack's CI/CD pipeline to inject 84 malicious npm versions. Despite carrying valid SLSA Build Level 3…

Between 19:20 and 19:26 UTC on May 11, 2026, the threat actor known as TeamPCP successfully injected 84 malicious versions into the TanStack CI/CD pipeline. These packages, signed with perfectly valid SLSA Build Level 3 attestations, infiltrated one of the most widely used frontend libraries in the world. The payload is not limited to credential theft; if a maintainer revokes the compromised GitHub token, a local wiper initiates data deletion, effectively turning the standard incident response process into a destructive trap.

Key Takeaways

The attack utilized a three-stage abuse of GitHub Actions: pull_request_target exploitation, cache poisoning, and the runtime extraction of an OIDC token from runner memory via /proc/<pid>/mem, bypassing the need for stolen npm credentials.
The malicious versions carry valid SLSA Build Level 3 attestations issued by Sigstore, which certify the compromised pipeline as legitimate, effectively deceiving both automated security tools and developers.
The payload functions as a self-propagating worm, leveraging trusted publishing to generate new compromised packages and installing the gh-token-monitor daemon, which executes rm -rf ~/ if it detects a 40X error during token validation.
TanStack confirmed that no npm tokens were stolen and the publication workflow itself was not directly breached. However, the potential impact is massive, with @tanstack/react-router estimated at 12 million weekly downloads and 169 package names identified across 373 malicious npm entries.

How TanStack’s CI/CD Fell: A Triple-Threat GitHub Actions Abuse

The initial entry point was a fork named zblgg/configuration and a subsequent pull request (#7378) against the TanStack/router repository. Snyk’s analysis indicates the flow exploited pull_request_target, a configuration often used to run workflows on external code with elevated privileges. This led to cache poisoning, where attackers polluted the shared pnpm runner cache to inject malicious code into the legitimate build process.

The critical escalation involved the runtime extraction of an OIDC token from the GitHub Actions runner memory. By analyzing /proc/<pid>/mem, the payload captured the federated identity token before the legitimate workflow concluded. This token was then used to publish the 84 compromised versions directly to npm, circumventing the need for traditional npm credentials. TanStack verified that the npm publish workflow was not breached and no npm tokens were exfiltrated.

The SLSA Dilemma: Why Level 3 Attestations Signed Malware

These malicious versions are not clever fakes; they carry verified SLSA Build Level 3 attestations from Sigstore, making them indistinguishable from genuine releases to most automated scanners. This highlights an architectural challenge: SLSA certifies *which* pipeline produced an artifact, not whether that pipeline's behavior remained benign.

"SLSA provenance confirms which pipeline produced the artifact, not whether the pipeline was behaving as intended"
— StepSecurity

In this instance, the provenance system functioned exactly as designed, certifying a build process that had been hijacked from within. For developers relying on these attestations as a proxy for trust, the incident exposes a flaw in current threat models: the pipeline was compromised, yet the digital signature signaled total security.

Self-Propagating Worm and the Defense-Triggered Wiper

Within the tarballs, Wiz and Snyk isolated an obfuscated 2.3 MB file named router_init.js and an optionalDependency that uses Bun's prepare hook to execute the payload. The code steals credentials and uses the "trusted publishing" mechanism to replicate itself by publishing further compromised packages. This self-sustaining nature defines the "Mini Shai-Hulud" worm: it doesn't wait for remote commands but uses the victim's own tokens to spread.

The most insidious component is the gh-token-monitor daemon documented by Wiz. Every 60 seconds, it queries GitHub APIs; if it detects a 40X error—the hallmark of token revocation—it attempts to execute rm -rf ~/, wiping the local data of the infected machine. While the daemon self-terminates after 24 hours, during that window, a standard defensive reaction becomes a trigger for destruction. While actual damage from the wiper remains unconfirmed, the capability is present and operational.

Exfiltration Channels and Attribution to TeamPCP

Stolen data is exfiltrated through a redundant network of three parallel channels. The first is a typosquatted domain, git-tanstack[.]com, designed to blend with legitimate traffic. The second utilizes the Session Protocol network. The third functions as a dead-drop on the GitHub API, using a repository titled ‘Shai-Hulud: Here We Go Again.’ Wiz has attributed the operation to TeamPCP with high confidence.

The incident is tracked as CVE-2026-45321, carrying a CVSS score of 9.6. The total number of compromised environments has not yet been quantified, and it remains unverified if the worm successfully propagated to other maintainers beyond those already identified. The scale of exposure, however, is clear: over 12 million weekly downloads for @tanstack/react-router and an npm ecosystem that ingested 169 package names with 373 malicious entries.

Incident Response and Mitigation Strategy

Audit Installations: Search for @tanstack packages updated on May 11, 2026, between 19:20 and 19:26 UTC. Compare installed versions against the 373 malicious entries documented by Aikido on npm. Remediate findings before revoking any tokens.
Do Not Revoke Tokens on Live Machines: Isolate suspected systems from the network before deactivating GitHub tokens to prevent triggering the gh-token-monitor wiper and the subsequent rm -rf ~/ command.
Review GitHub Actions Workflows: Eliminate unnecessary use of pull_request_target and shared caches between untrusted jobs. Restrict OIDC runner permissions to the absolute minimum and monitor for unauthorized access to /proc/*/mem.
Decouple Trust from Provenance: Treat SLSA attestations as pipeline verification rather than a guarantee of source code integrity. Implement package pinning via hashes and perform independent code audits prior to installation.

The TanStack breach is more than a credential theft; it is a demonstration of how defense-in-depth can be weaponized against the responder. Token revocation—a reflex for any security team—acts here as a detonator. For organizations that viewed SLSA attestations as a shortcut to trust, the message is clear: the pipeline is merely a process, never a substitute for human oversight of the code itself.

Frequently Asked Questions

Were npm or GitHub servers directly compromised?

No. Neither npm nor GitHub were breached. The attackers abused legitimate features such as pull_request_target, runner caching, and OIDC trusted publishing to hijack the pipeline without breaking the services' perimeters.

Why were the SLSA attestations valid if the code was malicious?

Sigstore-verified SLSA Build Level 3 attestations certify which pipeline generated the artifact, not the intent of the source code fed into that pipeline. Because the build runner was compromised, the signature was technically correct even though the content was toxic.

What is the risk of revoking a GitHub token on an infected machine?

The gh-token-monitor daemon interprets a 40X API error as a sign of revocation and triggers rm -rf ~/ to delete local data. Therefore, the first priority should be network isolation, not immediate revocation.

Information has been verified against cited sources and is current as of the time of publication.