An npm Worm Just Hit 2 Billion Installs. Audit Your Stack.

On August 4, attackers took over the GitHub account of the maintainer behind keyv, a caching library that gets roughly 127 million downloads a week on npm. Within hours, a self-replicating worm dubbed Shai-Hulud (yes, the Dune sandworm; the campaign's exfiltration repos are literally labeled "Shai-Hulud: Here We Go Again") had spread malicious code across the maintainer's entire package family and beyond: flat-cache, file-entry-cache, cacheable-request, cache-manager, and hundreds more.

By early afternoon European time, security firm Aikido counted at least 434 compromised packages across 1,381 versions, with a combined total of over 2 billion monthly installs. Other trackers put the eventual count at 868 packages.

Here's why this matters to you specifically: if your startup ships anything built on Node, there's a decent chance something in your dependency tree touched one of these packages. And the payload wasn't subtle. It was built to steal every credential your company runs on.

The mechanics are worth understanding because they explain the defenses. Each poisoned package got a new preinstall script, which means the malware ran automatically the moment anyone (or any CI server) ran npm install. No click required.

The payload then went credential shopping. According to Aikido's teardown, it harvested npm publish tokens, GitHub tokens, AWS keys (including from Secrets Manager across multiple regions), Kubernetes service account secrets, HashiCorp Vault tokens, Stripe API keys, Slack tokens, SSH keys, and every .env file it could find. It encrypted the loot and uploaded it to public GitHub repositories, around 1,300 of them at last count.

Then came the worm part. Any stolen npm token got used immediately to publish infected versions of every package that token could touch. Stolen GitHub tokens were used to commit malicious hooks into .vscode/tasks.json and .claude/settings.json files across up to 50 branches per repo, disguised as a routine "chore: update config" commit. That's how one maintainer's bad day became 400-plus infected packages by lunchtime.

Because the blast radius isn't a technical inconvenience. It's your company's bank account, customer data, and reputation.

Walk the chain: a stolen Stripe key can read your payment data. A stolen AWS key can read your production database, and your customers' data inside it. A stolen Slack token reads your internal conversations. And once customer data leaks, you're into breach notification territory, which for an early-stage company means legal costs, churned customers, and awkward questions in your next fundraise or enterprise security review.

Suno, the AI music startup, spent late July dealing with exactly those questions after its own breach. Security reviews are increasingly where enterprise deals are won or lost, and "we got swept up in a supply chain worm and hadn't rotated keys in a year" is not an answer that closes contracts.

The good news: the defenses here are cheap, mostly configuration and habit rather than headcount. This is one of the few security areas where a two-person startup can reach a defensible posture in a week.

Before the playbook, triage. Have whoever runs your codebase do three things today.

One, check your lockfiles for the compromised versions. The headline ones: keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cache-manager 7.2.10. Security vendors including Aikido, Wiz, and Cloudsmith published fuller lists with indicators of compromise.

Two, search your repos for the dropped files: setup.mjs and Math_Symbol.js (or math_init.js in second-generation infections), plus any surprise edits to .vscode/tasks.json or .claude/settings.json authored by a "claude" user you don't recognize.

Three, if you find anything, assume every secret on the affected machines is burned. Rotate npm and GitHub tokens first (those spread the worm), then cloud, payment, and messaging credentials. Rotation is annoying. It is dramatically less annoying than explaining to customers why their data appeared in a public GitHub repo.

Pin your dependencies and commit lockfiles. A lockfile means installs use exact known versions instead of grabbing whatever's newest. Most victims of August 4 were hit because a fresh install pulled the poisoned version published minutes earlier.

Turn off install scripts where you can. Setting ignore-scripts to true in npm config neuters the preinstall trick entirely. Some packages need scripts to build, so this takes testing, but it removes the single most abused mechanism in npm attacks.

Add a cooldown for new versions. Configure your tooling to only adopt package versions that are at least a few days old. Poisoned releases are usually caught within hours; a 3 to 7 day delay lets other people be your early warning system.

Scan continuously. Free and cheap tools (GitHub's Dependabot alerts, Aikido's free tier, Socket, npm audit) flag known-bad versions automatically.

Prune. Every dependency is a door. If a package saves you 20 lines of code, write the 20 lines.

The second half of the defense is making stolen machines less valuable.

Scope your tokens. A CI token that can only publish one package can't infect fifty. GitHub fine-grained tokens and npm granular tokens exist for exactly this reason; the era of one god-token in a .env file needs to end at your company this month.

Get secrets out of files. The worm's filesystem scanner ran roughly 200 search patterns hunting for .env files, private keys, and config files. Secrets that live in a proper secrets manager, injected at runtime and scoped per service, mostly don't show up in that net. (Caveat from this incident: the payload could enumerate AWS Secrets Manager with a stolen AWS key, so the key itself needs scoping too. Least privilege all the way down.)

Require hardware-key two-factor on npm and GitHub for anyone who can publish. The original compromise here was a maintainer account takeover. Your accounts are the same attack surface.

And set a calendar reminder to rotate high-value keys quarterly. Stale credentials are the ones that hurt longest.

The mistake most early teams make is treating security as a project you do once instead of a line item you review forever. The fix is structural: put dependencies on the same review cadence as your other business risks.

Once a quarter, spend an hour on four questions. What are our 10 most critical dependencies, the ones that would hurt worst if compromised? Who on the team would know within 24 hours if one of them shipped malware? Which credentials would a compromised laptop expose, and when were they last rotated? What's our one-page response plan if we wake up to the next Shai-Hulud?

Write the answers down somewhere the whole team can see, the same place you keep your other planning docs. Some founders keep this in a wiki; others fold it into a risk section of their operating plan in a tool like Foundra or Notion, next to competitive analysis and runway, which is where it belongs. A dependency you can't live without is a business risk, not just an engineering detail.

Zoom out and August 4 wasn't an anomaly. It was the third major package-registry attack this year, after RubyGems' SleeperGem campaign hit dormant maintainer accounts in July. The techniques keep improving: this variant fetched its backup exfiltration domain from an Ethereum smart contract so defenders can't kill it by seizing one server, and it planted hooks in editor config files so the payload runs even without an npm install.

Attackers have concluded, correctly, that compromising one exhausted open-source maintainer is cheaper than breaching a thousand companies one at a time. That math won't change, so the attacks won't stop.

For founders, the takeaway isn't fear. It's that the free software your company is built on comes with a maintenance obligation, and the startups that treat dependency hygiene as routine operations, boring and scheduled, are the ones that will read about the next worm instead of starring in the incident report.

• On August 4, 2026, the Shai-Hulud worm compromised keyv and hundreds of related npm packages totaling over 2 billion monthly installs, stealing credentials via automatic preinstall scripts.
• The payload hunted npm, GitHub, AWS, Kubernetes, Vault, Stripe, and Slack credentials, then used stolen tokens to self-replicate across more packages and repos.
• Triage now: check lockfiles against published compromised versions, search for dropped files, and rotate any potentially exposed secrets.
• Five cheap habits block most supply chain attacks: pinned lockfiles, disabled install scripts, version cooldowns, continuous scanning, and fewer dependencies.
• Scoped tokens, runtime secrets, and hardware two-factor make a compromised machine far less valuable to an attacker.
• Put dependency risk on a quarterly review cadence alongside runway and competition. It's a business risk that happens to live in code.

We don't use keyv directly. Are we safe? Not automatically. These libraries are dependencies of other dependencies; flat-cache alone rides along with hugely popular tools. Check your lockfile, which lists everything installed, not just what you added on purpose.

We found a compromised version but the malware may not have run. Now what? Assume it ran. Rotate npm, GitHub, cloud, payment, and messaging credentials from a clean machine, check npm and GitHub audit logs for publishes and commits you didn't make, and review recently changed .vscode and .claude config files.

Does this affect Python, Ruby, or other ecosystems? The same pattern does. RubyGems saw the SleeperGem campaign in July 2026, and PyPI has had its own incidents. The playbook (pinning, scanning, scoped credentials) transfers almost unchanged.

We're two people with no security budget. What's the minimum? Commit lockfiles, enable Dependabot or a free scanner tier, turn on hardware-key two-factor for GitHub and npm, and keep secrets out of committed files. That's a weekend of work and it covers the worst of it.

How would we even hear about the next attack in time? Follow your scanner's alerts, and have one named person subscribed to a feed like Aikido Intel or the npm security advisories. Detection within a day is usually early enough if your versions have a cooldown delay.

1. Aikido Security: Keyv and friends compromised in active Shai-Hulud supply chain attack
2. Wiz Blog: keyv and cacheable npm supply chain attack
3. Cloudsmith: Keyv and Cacheable npm packages compromised in active supply-chain attack
4. DevOps.com: Fast-moving Shai-Hulud attack infects npm packages with 2 billion monthly downloads
5. Cybersecurity News: Keyv npm package with 127M weekly downloads compromised