Mini Shai-Hulud: The Next Evolution of NPM Supply Chain Worms
A deep dive into the Mini Shai-Hulud attack, a sophisticated NPM worm that uses the Bun runtime to bypass security and targets developer agents for persistence.
On April 29, 2026—incidentally my 35th birthday—the open-source ecosystem received a gift nobody wanted: Mini Shai-Hulud.
This isn't just another malicious package. It represents a paradigm shift in supply chain threats: a highly autonomous NPM supply chain worm. Instead of just sitting in a registry, it harvests credentials, backdoors other packages, and persists within the very tools developers use to build and secure their code.

The Anatomy of a Worm
Mini Shai-Hulud is the third iteration of a lineage that started in late 2025. While previous versions were simpler, this variant is a sophisticated agent-targeting predator.
The attack heavily targeted the SAP cloud application development ecosystem, infecting core utilities like @cap-js/sqlite and @cap-js/postgres. Once it gains a foothold, it harvests NPM publish tokens and uses them to automatically backdoor other NPM packages maintained by the victim.
How it Spreads (and Bypasses Security)
The worm exploits the trust we place in lifecycle scripts, but with a clever twist:
- The Hook: The infection starts with a
preinstallhook in a compromised package. - The Loader: This hook executes a loader script (
setup.mjs) which functions as a bootstrapper. - The Runtime Bypass: Instead of using Node.js—where many security tools and linters are focused—it downloads its own: the Bun JavaScript runtime engine.
- The Payload: Using Bun, it executes
execution.js, a heavily obfuscated 11.7 MB credential stealer. By using a separate runtime, it effectively evades security tooling that specifically monitors Node.js system calls.
Persistence: Targeting the Developer Agent
What makes Mini Shai-Hulud particularly dangerous is how it targets the "inner loop" of development. It installs persistence hooks directly within developer tool configurations:
- VS Code: It modifies
.vscode/tasks.json, injecting a payload with a"runOn": "folderOpen"setting. This means the malware triggers the moment a developer simply opens the infected repository in VS Code. - Claude Code: It modifies
.claude/settings.jsonto abuse theSessionStarthook, ensuring it runs whenever you start a new coding session with the agent.
By embedding itself in these agentic workflows, the worm ensures its code executes continuously, even if the original malicious package is removed from node_modules.
Mitigation: How to Defend Your Factory
Defending against an autonomous worm requires hardening the environment where code is built and developed.
1. Disable Lifecycle Scripts
The primary execution vector for Shai-Hulud is the preinstall script. Unless you know exactly what a package needs to do at install time, you should disable these scripts globally:
# For NPM
npm install --ignore-scripts
# For Yarn
yarn install --ignore-scripts
2. Monitor for Secondary Runtimes
Security teams should look for anomalous child processes being spawned during package installation. If npm install suddenly triggers the download or execution of bun or curl/wget to external domains, it's a high-fidelity indicator of a supply chain compromise.
3. Use Docker Sandboxes (sbx)
Docker Sandboxes (currently Early Access) put your AI coding agent in an isolated microVM environment. The sandboxed AI agent can build containers, install packages, and modify files without accessing your host system. This means that even if a malicious package tries to execute a script, it won't have access to your host's file system or network, effectively neutering the worm's ability to persist or exfiltrate data.
They say to kill the Shai-Hulud, put it in a box of sand and pour water on it.
4. Ephemeral Identities (OIDC)
The worm's goal is to harvest long-lived tokens (PATs, AWS keys). If you move to OpenID Connect (OIDC) for your CI/CD pipelines, you replace static secrets with short-lived, ephemeral tokens that expire before the worm can even begin its exfiltration process.
Beyond the SBOM
Mini Shai-Hulud proves that an SBOM is a "receipt," not a "shield." It tells you what's in the box, but it doesn't stop the box from attacking your IDE when you open it.
The future of supply chain security lies in cryptographic verifiability, ephemeral identities (OIDC), and runtime defense using tools like Docker Sandboxes to isolate the build process from the host.
Stay safe, and maybe keep an extra eye on your .vscode/tasks.json this week.
For a deeper dive into the "Beyond SBOMs" framework, join me at DevOpsDays Zurich or WeAreDevelopers Berlin later this year.