A Self-Propagating npm Worm Is Stealing Every Secret It Can Find: Shai-Hulud / ChainDrop, Explained

Quick answer: ChainDrop — flagged by its own calling card, public GitHub repos titled “Shai-Hulud: Here We Go Again” — is a self-propagating npm worm that compromised more than 400 packages starting August 4, 2026. It hijacks a maintainer’s account, publishes a malicious version with a preinstall script, and when anyone installs it, harvests their cloud keys, GitHub and npm tokens, SSH keys, CI/CD secrets, crypto wallets, and AI tool configs. Then it uses the stolen npm publish token to infect that victim’s own packages — which is how it spreads on its own. If you installed an affected package, treat every secret on that machine as compromised and rotate now. The exact packages, indicators, and response steps are below.

First, what is a “supply-chain” attack — and npm?

Almost no modern software is written from scratch. Developers assemble it from thousands of small open-source building blocks — packages — pulled automatically from public registries. For JavaScript, that registry is npm, and a single app can depend on hundreds of packages, which each depend on hundreds more. A software supply-chain attack skips your defenses entirely: instead of breaking into your app, the attacker poisons one of the building blocks you already trust and pull in automatically. You don’t click anything. The code runs the moment you install.

What happened

Attackers got hold of npm maintainer credentials and published malicious versions of popular caching packages directly to the registry — among them keyv (v6.0.0), cache-manager (v7.2.10), cacheable-request (v13.0.20), @cacheable/utils (v2.5.1), and flat-cache. Because these are foundational utilities buried deep in the dependency tree, the blast radius was enormous: 400+ packages across unrelated publishers, with billions of monthly downloads between them. Most victims had never heard of the package that infected them — it was three layers down in something else they installed.

How it works: three stages, then it self-replicates

The malicious packages ran a classic install-time attack chain — the code executes before any of your tests or security checks do:

• Stage 1 — Preinstall hook. Each poisoned package adds a "preinstall" lifecycle script that launches setup.mjs before npm even finishes installing.
• Stage 2 — Loader. setup.mjs runs a large, heavily obfuscated payload built on the Bun JavaScript runtime — chosen partly to dodge Node-focused tooling.
• Stage 3 — Payload. The Bun bundle does the actual work: harvest credentials, then spread.

The spread is what makes it a worm, not just a bad package. Once it has a victim’s npm publish token, the malware downloads that person’s own packages, injects itself, bumps the patch version, and republishes them to npm — automatically. As the researchers put it: one stolen token can produce malicious releases across every package that publisher owns. So each infected maintainer becomes a new distribution point, and the compromise cascades through the ecosystem without any human at the keyboard.

What it steals — and it’s almost everything

This isn’t a targeted grab. The payload systematically sweeps the machine and the identities it can reach:

Worse, it doesn’t just grab files — it uses the credentials it finds to call cloud and service APIs, confirm what access they grant, and pull down additional secrets those identities can reach. One leaked key becomes a foothold into everything that key can touch. Stolen data is encrypted (AES-256-GCM) and exfiltrated to attacker-controlled domains, with a fallback of dumping it into public GitHub repos.

The inclusion of AI tool configs is notable — and exactly the modern secret-sprawl problem we keep flagging. Developer machines now hold Claude, OpenAI, Cursor and Gemini keys alongside cloud credentials, and malware has learned to look for them. It’s the same exposure Prompt Guard was built to contain, seen from the other direction.

Am I affected? How to check

• Check your lockfile and node_modules for the compromised versions — keyv 6.0.0, cache-manager 7.2.10, cacheable-request 13.0.20, @cacheable/utils 2.5.1, flat-cache — and their transitive presence (they’re usually pulled in indirectly). Wiz publishes the full package list.
• Hunt the indicators of compromise below in your build logs, CI runners, and developer machines — especially anything that ran npm install after August 4, 2026.
• Assume install-time execution: if a poisoned version was installed anywhere, the preinstall script already ran with that machine’s privileges.

How to respond

If you installed an affected package, treat the machine and its identities as compromised. Speed matters — the stolen tokens are being used programmatically.

• Remove the affected package versions from every environment — developer machines, build servers, and CI/CD — and pin to known-good versions in your lockfile.
• Rotate everything the host could see: npm tokens, GitHub tokens and SSH keys, AWS/Azure/GCP credentials, Kubernetes and Terraform creds, CI/CD secrets, AI API keys, and any crypto wallet keys.
• Audit for abuse: review cloud and source-control logs for unauthorized access, unexpected npm publishes from your account, and new public GitHub repos.
• Rebuild, don’t clean: any machine that executed the payload should be treated as fully compromised and reimaged.

How to stop the next one

• Disable install scripts by default: npm install --ignore-scripts (and enable scripts only for the few packages that genuinely need them). This alone neutralizes preinstall-hook attacks.
• Pin exact versions with a committed lockfile, and gate dependency updates through review — don’t auto-upgrade.
• Turn on provenance and integrity verification, and use dependency allowlisting where your tooling supports it.
• Keep long-lived secrets off developer and CI machines — prefer short-lived, scoped tokens, so a theft is worth far less.

The bigger pattern: supply chain is the blind spot

ChainDrop is a perfect example of a threat class that never shows up in a traditional vulnerability scan — there is no “vulnerable version” to match, because the package itself became the malware. It’s the same reason exposed AI infrastructure slips past version-based scanners, and it’s a category we called out in our analysis of 1,307 recent advisories: the attacks landing today are about what you trust and expose, not just what you forgot to patch.

For a compliance program this is a CC6 and CC9 problem at once — logical access and malicious-software controls (SOC 2 CC6.1 / CC6.8) collide with third-party and supply-chain risk (CC9). CATAAM’s job is to turn exactly this into a tracked obligation: map the exposure to the SOC 2 controls it breaks, monitor it continuously, and — for the secret-theft half — keep credentials and AI keys from leaking in the first place with Prompt Guard. Start by seeing what you actually expose with a free external attack-surface scan.

You didn’t have to do anything wrong to be hit by this — you just had to build software the way everyone builds software. That’s exactly why the supply chain is where defenders have to look next.

Frequently asked questions

What is the Shai-Hulud / ChainDrop npm worm?

It’s a self-propagating npm supply-chain worm that began on August 4, 2026, compromising 400+ packages (including keyv, cache-manager, cacheable-request, @cacheable/utils and flat-cache). It hijacks maintainer accounts, publishes malicious versions with an install-time preinstall script, steals credentials from anyone who installs them, and then uses stolen npm publish tokens to infect the victim’s own packages — spreading automatically. “Shai-Hulud: Here We Go Again” is the marker it leaves in public GitHub repos.

What does it steal?

Almost every credential it can reach: npm and GitHub tokens, SSH keys, AWS/Azure/GCP and Kubernetes/Vault/Terraform credentials, CI/CD secrets (GitHub Actions OIDC, Jenkins, Argo CD, Harbor), AI tool configs and API keys (Claude, OpenAI, Cursor, Gemini), crypto wallets, and even /etc/shadow on Linux — then it uses those credentials to call APIs and pull down more secrets.

How do I know if I’m affected?

Check your lockfiles and node_modules for the compromised versions (including as transitive dependencies), and hunt the IOCs — the domains npm-cache[.]com / pypi-get[.]com / js-mirror[.]com, dropped files like setup.mjs and Math_*.js, unexpected Bun runtime activity (User-Agent Bun/1.3.13), and public GitHub repos described “Shai-Hulud: Here We Go Again.” Anything that ran npm install after August 4, 2026 is in scope.

What should I do if I installed an affected package?

Treat the machine and its identities as compromised: remove the malicious versions and pin known-good ones, rotate every secret the host could see (npm/GitHub/SSH/cloud/K8s/CI/AI keys/crypto), audit cloud and source-control logs for abuse, and reimage any host that executed the payload rather than trying to clean it.

How do I prevent install-time supply-chain attacks like this?

Install with npm install --ignore-scripts by default (this neutralizes preinstall-hook attacks), pin exact versions with a committed lockfile, gate dependency updates through review instead of auto-upgrading, enable provenance and integrity verification, and keep long-lived secrets off developer and CI machines in favor of short-lived, scoped tokens.