Worm Just Hacked 160+ is one of those subjects that keeps surfacing in every security conversation. I’ve been writing about cyber security long enough to know when something is genuinely scary. This one qualifies.
Over the past week, a worm called Mini Shai-Hulud tore through the npm JavaScript ecosystem like wildfire through dry grass. It compromised over 160 packages across 373 malicious versions – including major libraries from TanStack, Mistral AI, and UiPath. However, here’s the kicker: OpenAI confirmed that two of their employee devices were compromised in the attack.
How It Actually Worked
This wasn’t some basic phishing scam. The attackers pulled off a three-stage chain that security researchers are calling the first documented case of a malicious npm package carrying valid SLSA Build Level 3 provenance. That’s a big deal – it means the malware came with a legitimate-looking “certificate of authenticity.”
Here’s the chain:
- Hijacked GitHub Actions workflow: The attackers created a malicious pull request (#7378) that exploited a misconfigured GitHub Actions workflow using
pull_request_target. This ran attacker-controlled code inside the legitimate build. - Cache poisoning: The malicious code poisoned the pnpm package store cache with a specific key, which was later consumed by the legitimate release workflow.
- OIDC token theft: During the release build, attacker code extracted the OIDC token directly from runner memory and used it to publish malicious packages to npm – authenticated as TanStack’s own release workflow.
Once inside, the worm self-propagated. It would hijack an infected developer’s npm profile, append a malicious postinstall script to their package.json files, and spread to every package that developer maintained. It hit TanStack’s React Router, Vue Router, Solid Router, and router-core packages. It hit Mistral AI’s client library. It hit 40+ UiPath packages. However, it kept spreading.
The Really Nasty Bits
The malware wasn’t content with just stealing credentials. It installed editor persistence hooks in both Claude Code’s settings and VS Code’s task files. Every time a developer opened their editor, the malware would re-execute. It also installed a system service – on Linux via systemd, on macOS via LaunchAgents – that polled GitHub with the stolen token.
And then there was the dead-man’s switch: if the stolen GitHub token was revoked, the malware would run rm -rf ~/ and destroy the developer’s entire home directory. Let that sink in. You detect the malware, you try to do the right thing by revoking the token, and your machine nukes itself.
Stolen data was exfiltrated via the Session/Oxen P2P network and GitHub GraphQL API “dead-drop” commits – techniques designed to blend into normal traffic and evade detection.
What OpenAI Did
OpenAI published a detailed response confirming that two employee devices were compromised. They found no evidence that user data, production systems, or intellectual property were affected. But they rotated code-signing certificates across all platforms as a precaution.
The practical impact? Every macOS user needs to update their OpenAI apps by June 12, 2026 – ChatGPT Desktop, Codex, and Atlas. After that date, macOS will block apps signed with the old certificate. The last affected versions are ChatGPT Desktop 1.2026.125 and Codex 26.506.31421.
What You Need to Do Right Now
If your team uses any TanStack packages – and if you’re building React apps, there’s a good chance you do – here’s the priority list:
1. Check for compromise:
find node_modules/@tanstack -name "router_init.js" -exec shasum -a 256 {} \;The compromised hash is ab4fcadaec49c03278063dd269ea5eef82d24f2124a8e15d7b90f2fa8601266c.
2. Kill the dead-man’s switch immediately. Before you rotate anything, disable the persistence mechanisms. Remove the editor hooks. Remove any injected GitHub Actions workflows.
3. Rotate secrets in this order: npm tokens, GitHub PATs, AWS credentials, HashiCorp Vault tokens, Kubernetes service account tokens, SSH keys, and Claude Code session logs.
4. Block these domains at DNS: *.getsession.org, api.masscan.cloud, git-tanstack.com.
5. Audit your package-lock files for any of the 169 affected package names. The full list is in the Snyk advisory and Aikido’s analysis.
The Bigger Picture
This attack exposes something fundamental about how we build software today. The entire npm ecosystem runs on trust – you trust the maintainers, you trust the CI/CD pipelines, you trust that a signed package actually means it’s safe. Mini Shai-Hulud proved that provenance is not a safety signal. A package can have valid provenance from a trusted workflow, but if that workflow was hijacked, the build was compromised.
Supply chain attacks are no longer theoretical. They’re automated, they’re self-propagating, and they’re targeting the exact libraries your developers use every single day. The tools for defending against this exist – minimum release ages, provenance validation, strict dependency pinning – but most teams haven’t deployed them yet.
Every supply chain attack teaches the same lesson: the libraries you trust are only as secure as the pipelines that build them. If you haven’t audited your CI/CD workflows for pull_request_target misconfigurations, you’re not ready for what’s coming next.
Related Reading
- Why Password Managers Are More Important Than Ever – Even for Developers
- The Complete Online Safety Guide for Families
- How to Lock Down Your Privacy Settings Across Every Platform
The views expressed on this site are my own and do not represent those of any current or former employer. Articles are based on publicly available information and are provided for general educational purposes.
