Mini Shai-Hulud Worm: 170+ Packages Compromised as SLSA Protections Bypassed

The Mini Shai-Hulud worm has compromised over 170 npm and PyPI packages by exploiting GitHub Actions to generate valid SLSA attestations, effectively neutraliz…

On May 11, 2026, the threat group TeamPCP orchestrated a sophisticated supply chain attack using the Mini Shai-Hulud worm. The malware compromised over 170 npm and PyPI packages by exploiting a chain of vulnerabilities within GitHub Actions to publish malicious versions carrying valid SLSA attestations. In a window of just five hours, more than 400 infected versions were distributed, impacting major ecosystems including TanStack, Mistral AI, UiPath, OpenSearch, and Guardrails AI. This incident is particularly significant because it combines a destructive dead-man’s switch with the subversion of software provenance, creating a dangerous precedent that undermines trust in automated integrity mechanisms.

Key Takeaways

The worm targeted 42 packages across the TanStack, Mistral AI, UiPath, OpenSearch, and Guardrails AI ecosystems, with over 400 malicious versions published within a five-hour window.
The attack utilized a three-stage exploit chain in GitHub Actions—combining "Pwn Requests," cache poisoning, and OIDC token extraction from memory—to sign artifacts with legitimate SLSA attestations.
The malware includes a dead-man’s switch that executes rm -rf ~/ if a developer revokes the compromised npm token, turning standard incident response into a destructive trigger.
Infected TanStack packages alone account for approximately 12 million weekly downloads and carry a CVSS score of 9.6; cumulative downloads for all affected packages exceed 518 million.

The Triple Exploit Chain: From Cache Poisoning to OIDC Theft

The operation did not rely on stolen static credentials. Instead, it began with a malicious pull request targeting repositories that utilize the pull_request_target workflow. This technique, known as a "Pwn Request," allows for code execution within the context of the target repository without requiring manual approval. The initial payload injected contaminated files into the GitHub Actions cache, effectively poisoning the environment for subsequent legitimate runs.

When the official build workflow resumed, the jobs inherited the infected cache. At that point, the attacker's code searched for the Runner.Worker process, read /proc/<pid>/mem, and extracted the ephemeral OIDC token that GitHub uses to authenticate the runner with npm. Using this token, the worm published new package versions directly to the npm registry. This process generated a signed SLSA attestation through the official pipeline, bypassing the very integrity guarantees that provenance is designed to provide.

The Dead-Man’s Switch: Why Token Revocation Triggers Destruction

Mini Shai-Hulud goes beyond data exfiltration. The malware installs a daemon that continuously monitors the compromised npm token by polling the npm token endpoint. If the request returns a 40X error—the expected result when a owner revokes the token—the daemon triggers a wiper, executing rm -rf ~/ on the machine that performed the publication. The code comments are explicit: "If you revoke this token, it will wipe the owner's computer."

This mechanism serves as a trap: the standard defensive reaction—immediately revoking a suspicious token—becomes the catalyst for local data destruction, including working repositories and configurations. Security analysts recommend a full system sanitization before attempting any revocation, as a compromised host will react by deleting all accessible files.

The SLSA Shortfall: When the Pipeline is Signed After Compromise

The most alarming aspect of this attack is that the malicious packages were issued valid SLSA attestations. As confirmed by Ashish Kurmi of StepSecurity, this represents the "first documented npm worm that produces validly [SLSA] attested packages." The provenance protocol did not fail in its technical execution; rather, it accurately certified an artifact produced by a pipeline that had already been compromised.

The core issue lies in the timing of the signature: the attestation is issued after the code has already executed within the pipeline. If an attacker injects code prior to that point, the attestation becomes a "seal of approval" for malware. This distinction forces DevOps teams to shift their security focus upstream, verifying the integrity of the build environment itself rather than relying solely on the artifact's origin.

“It is the first documented npm worm that produces validly [SLSA] attested packages.” – Ashish Kurmi, StepSecurity

Beyond Europe: Geofencing and Decentralized Infrastructure

The malware employs sophisticated geographic evasion techniques. It terminates execution if it detects Russian language settings and has a 1-in-6 probability of activating when the location matches Israel or Iran, likely to reduce exposure in regions where the attackers might fear immediate legal or retaliatory consequences. For data exfiltration, the worm utilizes the decentralized Session protocol, typosquatted domains, and GitHub "dead-drop" repositories to complicate traffic analysis.

While the infrastructure is advanced, several questions remain. The exact number of organizations that executed the infected packages before their removal is unknown, and the true identity of the TeamPCP group remains hidden behind the pseudonym DeadCatx3. It has been clarified that TanStack did not suffer a direct token theft; rather, its CI/CD flows were hijacked via cache poisoning.

Incident Response Guidance

1. Do not revoke npm tokens without first isolating the host. If the dead-man’s switch is active, revocation will trigger local data deletion. Power down the machine or disconnect it from the network, scan the filesystem for the gh-token-monitor daemon, and only then proceed with revocation.

2. Audit and restrict pull_request_target workflows. This is the primary attack surface. Replace them with standard pull_request workflows where possible or implement isolated build environments with robust sandboxing to mitigate cache poisoning risks.

3. Verify runner integrity prior to signing. Implement environment checksums, compare runner outputs against known baselines, and monitor for unauthorized access to /proc/<pid>/mem. SLSA attestations must be paired with evidence that the pipeline environment remained untampered during the build.

4. Inspect dependencies of recently affected releases. Verify the hashes of TanStack packages (and other affected ecosystems) currently installed. While malicious versions have been removed from npm, systems that ran npm install during the infection window may still have malicious copies in local caches or lockfiles.

The Mini Shai-Hulud attack fundamentally alters the supply chain incident response playbook. Provenance alone cannot guarantee security if the build source is contaminated. The rush to remediate with a simple token revocation is exactly the error this malware is designed to exploit. For Security and DevOps teams, the lesson is clear: integrity is measured by what happens before the signature, not just the signature itself.

Sources

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