What if the most secure packages in your supply chain were the ones that got you hacked?
The Mini Shai-Hulud campaign proved exactly that. On May 11, 2026, threat actor TeamPCP compromised over 170 packages across npm and PyPI – all carrying valid SLSA Build Level 3 provenance, the highest standard of supply chain security. Within 48 hours, 403 malicious versions had spread, affecting 518 million downloads and major projects including TanStack, Mistral AI, UiPath, and OpenSearch.
What makes Mini Shai-Hulud particularly alarming is its sophistication. The payload included anti-analysis features like a Russian language pack check and a dead-man’s switch that wipes the victim’s machine if stolen tokens are revoked. This is no longer simple code injection – it’s infrastructure-level compromise designed to persist, evade detection, and retaliate.
What Happened
At 19:20 UTC on May 11, the first malicious @tanstack packages began appearing in the npm registry. By 19:26 – just six minutes later – 84 malicious versions across 42 @tanstack packages had been published. The attackers had achieved something previously thought nearly impossible at this scale: they had poisoned GitHub Actions caches, extracted OIDC tokens directly from runner memory, and used those tokens to publish packages that looked completely legitimate to downstream consumers.
Within hours the worm had jumped ecosystems, compromising PyPI packages including mistralai and guardrails-ai. By May 12, the full scope was clear: 172 unique packages and 403 malicious versions. The attack affected organizations from early-stage startups to OpenAI, which later confirmed it had ingested a compromised dependency but contained the blast radius with no user data loss.
The speed and technical sophistication of this campaign – combined with a dead-man’s switch that wipes the victim’s home directory if tokens are revoked – suggests this is part of a maturing, well-resourced operation rather than an isolated incident.
Scope and Impact
The attack affected four major ecosystems and hundreds of organizations:
- @tanstack/* packages – 42 packages, 84 malicious versions published in 6 minutes
- PyPI cross-ecosystem jump – mistralai, guardrails-ai, and others compromised within 6 hours
- GitHub repositories – 379 repos created with stolen credentials
- Download impact – 518 million cumulative downloads affected
Organizations from early-stage startups to OpenAI were impacted. OpenAI publicly confirmed exposure but contained the blast radius with no user data loss, demonstrating effective incident response.
Technical Breakdown
Payload Delivery
The malicious payload was delivered through a sophisticated chain of techniques:
- Malicious fork creation – Attackers created a fork of the legitimate TanStack repository
- pull_request_target workflow abuse – Leveraged GitHub Actions workflow permissions to execute arbitrary code
- GitHub Actions cache poisoning – Injected malicious code into the build cache layer
- In-memory OIDC token extraction – Extracted authentication tokens directly from runner memory
The 2.34 MB router_init.js payload used JavaScript obfuscation, Fisher-Yates cipher, and AES-256-GCM encryption, making static analysis significantly more difficult.
Obfuscation & Anti-Analysis
The payload contained several notable anti-analysis and targeting features:
- Russian language pack check – The malware altered behavior based on system locale settings (confirmed by Microsoft Threat Intelligence). This is believed to be either a targeting mechanism or an attempt to avoid analysis in certain environments.
- Dead-man’s switch threat string – If a stolen token was revoked, the malware would display:
"IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner"before executingrm -rf ~/. - Multi-layered obfuscation – The payload used JavaScript obfuscation, Fisher-Yates cipher, and AES-256-GCM encryption.
Detection and Indicators
File System IOCs
~/.claude/hooks/gh-token-monitor– Malicious token monitoring service~/.local/bin/claude– Malicious Claude CLI wrappernode_modules/.package-lock.json– Modified lockfile with malicious entries
Network IOCs
45.61.136.237:443– C2 server for token exfiltrationcdn.sessionstack[.]com– Legitimate-looking domain for P2P exfiltration
Behavioral/GitHub Indicators
- Repositories containing “Shai-Hulud: Here We Go Again” string
- Unexpected
gh auth tokencommands in workflow logs - Modified
package.jsonwith suspiciouspreinstallorpreparescripts
Response and Mitigation
Teams that may have installed affected packages should take these steps in this exact order:
- Identify – Run SCA tools against all lockfiles and container images.
- Isolate – Immediately disable any
gh-token-monitorservices or.claude/hooks before rotating credentials. - Rotate – Revoke and rotate all potentially exposed credentials.
- Downgrade – Pin all affected packages to versions published before May 11, 2026.
- Hunt – Search GitHub organizations for repositories containing “Shai-Hulud: Here We Go Again”.
- Harden – Disable
preinstallandpreparelifecycle hooks globally. Enforce 24-hour delay before installing new packages.
Broader Context & Lessons Learned
This attack is not an isolated incident – it is part of a clear, accelerating trend in 2026 supply chain warfare. The “Shai-Hulud” branding itself is a deliberate callback to TeamPCP’s 2025 campaign, signaling attacker confidence and brand-building. What we’re seeing is the professionalization of supply chain attacks: well-resourced groups treating package ecosystems as strategic infrastructure to be captured, monetized, and defended.
This speed and sophistication is no longer exceptional – it is becoming the baseline for supply chain attacks in 2026.
The Big Picture: Why 2026 Looks Like This
Three structural shifts explain why we’re seeing this wave of attacks:
Understanding SLSA Levels: SLSA (Supply-chain Levels for Software Artifacts) is an industry standard for supply chain security. Levels range from 0 (no guarantees) to 4 (hermetic, reproducible builds with verified provenance). Level 3 – the level this attack bypassed – requires hardened build environments, verified reproducible builds, and cryptographically signed provenance attestations. Until now, Level 3 was considered the strongest practical protection.
- Provenance has been commoditized – SLSA, Sigstore, and similar frameworks were designed to solve the “is this package authentic?” problem. Attackers have now solved the harder problem: “can I make my malicious package look authentic?” Cache poisoning + runner memory extraction has made provenance a checkbox, not a guarantee.
- The economics favor attackers – A successful supply chain attack can yield thousands of credentials, GitHub tokens, and downstream access. The ROI is massive compared to traditional attacks. Professional groups are now treating package ecosystems as strategic infrastructure worth capturing and defending.
- Defenders are still playing whack-a-mole – Most organizations still treat supply chain security as “don’t install shady packages.” They have no visibility into what their lockfiles actually resolve to, no behavioral monitoring for
preinstallhooks, and no process for handling a token that might trigger a wiper if revoked. The asymmetry is extreme.
Key Lessons from Affected Projects
From TanStack’s postmortem: Even with rigorous code review and provenance, the attack succeeded because the malicious code never touched the source repository – it was injected at the build cache layer. Their key takeaway: “We now treat every CI runner as a potential attacker.”
From Mistral AI’s response: The cross-ecosystem jump from npm to PyPI happened in hours, not days. Their lesson: “We can no longer assume that security in one package ecosystem protects us in another.”
From UiPath and OpenSearch: Both emphasized the importance of the 7-day delay rule. “If we had waited 48 hours before consuming new packages, we would have avoided this entirely.”
Core Controls for Supply Chain Security
After reviewing dozens of 2025–2026 supply chain campaigns, one pattern is clear: organizations that treat every package install as untrusted code execution survive. Everyone else eventually gets hit.
The practical takeaway is not “rotate your keys faster.” It’s to build a supply chain security posture around these concrete, operational controls:
1. Delay Package Installs (The 7-Day Rule)
Never install a package published in the last 7 days. Most malicious packages are discovered and removed within 48–72 hours. A simple policy – “no package younger than 7 days” – would have completely blocked this campaign and most others in 2025–2026. This is the single highest-ROI control available.
2. Audit Your CI Runners (Monthly)
Most organizations have no idea what their CI runners actually have access to. Monthly audits should include:
- What secrets/tokens are available to each runner (GitHub OIDC, cloud credentials, registry tokens)?
- Can runners write to package registries? Should they?
- Are runners using short-lived, just-in-time credentials or long-lived persistent tokens?
- Is there behavioral monitoring for
preinstall/preparehooks executing during builds?
3. Design for Token Theft (Assume It Will Happen)
- Use short-lived, just-in-time credentials wherever possible – never persistent secrets in CI.
- Have a documented process to disable token-monitoring daemons before rotating any credential (critical to prevent wiper activation).
- Assume any stolen token has a 24–48 hour window before it triggers destructive behavior – plan your rotation timeline accordingly.
Everything else – SCA tools, provenance checks, lockfile auditing – is table stakes. These are necessary but no longer sufficient. The organizations that will survive the next wave are the ones that have internalized this new reality:
Supply chain attacks are no longer about code injection. They’re about infrastructure compromise, persistence mechanisms, and retaliation capability.
- Infrastructure – Attackers target CI runners, build caches, and credential stores rather than source code
- Persistence – Malicious code survives provenance checks, code review, and automated scanning through cache poisoning and memory extraction
- Retaliation – Payloads include dead-man’s switches, wipers, and anti-analysis features that activate when defenders respond
Internal Sources & References
Cited Sources:
1. TanStack Official Postmortem
2. Snyk Technical Analysis
3. GitHub Security Advisory GHSA-g7cv-rxg3-hmpx
4. OpenAI Security Response
5. Microsoft Threat Intelligence
6. Mistral AI Official Response (Cross-ecosystem security lessons)
7. UiPath Official Response (7-day delay rule emphasis)
8. OpenSearch Official Response (7-day delay rule emphasis)
About Fortreum
Need help securing your supply chain?
Fortreum helps organizations build resilient supply chain defenses against sophisticated attacks like the one described above. Our team has deep expertise in CI/CD security, credential protection, and behavioral monitoring for package ecosystems.
Let us know how Fortreum can help you navigate the changing currents of cybersecurity. For more information, visit the Fortreum website or follow the company on LinkedIn at LinkedIn.com/company/fortreum.
Should you have questions about your FedRAMP, CMMC, cloud and cybersecurity readiness, please reach out to us at Info@fortreum.com or Contact Us at https://fortreum.com/contact/