keyv Worm Hit 868 npm Packages. Check Your Lockfile Now

On August 4, 2026, attackers compromised the GitHub account of the maintainer behind `keyv`, a key-value storage library with roughly 127 million weekly npm downloads. And used that access to inject a credential-stealing worm across the entire package family. International Cyber Digest reported the attack compromised at least 868 npm packages carrying over 2 billion monthly installs, while Aikido's live tally was still climbing at 444 packages across 1,381 versions. The payload is an evolved version of the Shai-Hulud malware family. And it spreads itself by stealing your publishing tokens and republishing into every package it can reach. If you ship Node.js and you have not grepped your lockfile this week, close this tab and run the check before you read another word.

What Actually Got Compromised

The blast radius is not one popular library.

The maintainer account behind `keyv`, `cacheable`, `flat-cache`. And `file-entry-cache` all went down on August 4, 2026. And those are foundational caching utilities that live deep inside dependency trees most developers never inspect directly. Dev.to notes they are transitively required by tooling like ESLint, which means you can run an infected install without ever typing any of those names. SafeDep added that authentication libraries and high-download dependencies were among the poisoned packages. And that each victim's entire namespace was republished at about one package per second. The count grew that fast for a reason. This was not a single bad release, it was a coordinated namespace swap.

How The Worm Spreads Itself

The infection mechanism is a preinstall hook that fires the moment you run `npm install`.

International Cyber Digest describes `node setup.mjs` silently downloading a standalone Bun runtime to execute an obfuscated second-stage payload called `Math_Symbol.js` or `math_init.js`.

Once that payload runs, the X trending coverage reports it grabs credentials from npm, GitHub. And AWS, then uses the stolen tokens to infect more packages like `file-entry-cache` and `cache-manager`. The worm-like propagation is the part that turns a bad dependency into a rolling compromise. Wiz documented the same family auto-publishing malicious versions of any package it could access whenever it found additional npm tokens in the environment.

One compromised maintainer begets ten, and ten beget a thousand.

This Is Not A New Threat

The name Shai-Hulud has been circling npm for over a year. Wiz reported the earlier campaign on September 15, 2025, when malicious versions of multiple popular packages were published and their post-install scripts exfiltrated sensitive data to attacker-created public GitHub repos literally named Shai-Hulud. CISA later flagged a self-replicating worm publicly known as Shai-Hulud that had compromised over 500 packages. And NCSC New Zealand and Elastic Security Labs each published their own counts of an evolved version, Elastic clocking over 400 unique packages. Unit 42 investigated the renewed push under the name Shai-Hulud 2.0 and counted over 25,000 malicious repositories spread across about 350 unique users.

The story here is not a surprise attack.

It is an old pattern that kept working because nothing structural changed underneath it.

What Small Teams Should Do Right Now

This is the part that matters if you are a solo developer or a lean shop, as nobody is going to triage this for you. Here is the short version of what I am running against my own project lockfiles and what I would hand a client in the first hour.

- Grep every lockfile for the affected package names and versions. Start with `keyv`, `cacheable`, `flat-cache`, `file-entry-cache`, and `cache-manager`, then check anything published by the same maintainers in the August 2026 window. - Rotate anything that touched your CI in the exposure window. That means npm publish tokens, GitHub PATs, and AWS keys, since the payload explicitly hunts for those. Treat every secret in the build environment as exposed until proven otherwise. - Pin and re-resolve. Lockfile versions, not caret ranges, and rebuild from a known-good install before you trust the tree again.

The Real Lesson For Operators

The structural problem is that 127 million weekly downloads can pivot on a single maintainer's GitHub account. And no amount of careful version-pinning protects you when the trusted package itself ships the malware. Provenance signing verifies that a package came from the account it claims to come from. The trouble is that the account itself was the thing that got compromised. So the signature can be perfectly valid while the code is hostile. That is the uncomfortable center of this story. And it applies to every package registry that hands one person the keys to code that runs inside millions of builds. For small operators the answer is mechanical, not philosophical. Audit your tree, rotate your tokens, and stop trusting deep transitive dependencies you have never read.

What I Am Watching Next

The worm count was still moving when Aikido and International Cyber Digest filed their reports.

And the gap between 444, 500.

And 868 packages is the story of how fast this spread, not disagreement between researchers.

Unit 42's count of over 25,000 malicious repositories across about 350 unique users tells me the infrastructure for the next wave is already in place. Start with your lockfile tonight. If you want a second set of eyes, Mediascout audits dependency trees and CI secret exposure for small teams. So reach out and I will walk through yours.