SEM Devs
← All articles
The worm that infected keyv: inside August's npm supply chain attack
sicurezzasupply-chainnodejsdevops

The worm that infected keyv: inside August's npm supply chain attack

2 min read

On 4 August the GitHub account of the keyv maintainer was compromised, 127 million weekly downloads, and within two days a self-propagating worm poisoned over 1,300 package versions. You do not need to use keyv to be hit. What we checked across client pipelines.

On 4 August 2026 an attacker took over the GitHub account of the keyv maintainer, a key-value storage library with roughly 127 million weekly npm downloads, and from there injected a credential-stealing worm across the whole package family. By 6 August researchers counted over 1,300 compromised versions, a combined two billion downloads a month. If you run a Node project, the question is not whether you use keyv: it is whether one of your dependencies pulls it in without you noticing.

How the chain works

The malicious releases carry a Mini Shai-Hulud variant, renamed CHAINDROP: a heavily obfuscated JavaScript payload built on Bun that runs automatically through an npm preinstall lifecycle hook, before the package install even completes. The worm hunts for npm tokens, GitHub credentials and cloud keys on the machine, exfiltrates them and, if it finds a token with publish rights, republishes itself onto more packages. That is how it went from keyv to cacheable, flat-cache and file-entry-cache, dependencies almost nobody installs on purpose but that sit in half the ecosystem's tree.

Why the SME gets hit on the bounce

None of our clients depend on keyv directly. They all reach it transitively, through build tools, test frameworks and caching libraries. A single npm install run on a developer's laptop or a CI runner on 5 August was enough to execute the payload with that machine's credentials. The attack does not knock on the front door, it comes in through the dependency chain.

What we checked, in this order

  • Install dates: any npm install or npm ci between 4 and 6 August is treated as suspect until proven otherwise, on the laptop as much as on the runner.
  • Credentials on exposed machines: immediate rotation of npm and GitHub tokens, and of cloud keys present on runners that built in that window. A token-stealing worm only stops when you revoke them.
  • Lockfile against the registry: check that resolved versions are not the poisoned ones, and rebuild the tree from a clean lockfile.
  • Install-time scripts: in CI, npm ci --ignore-scripts defuses the entire preinstall attack class. Where a legitimate script is needed, run it explicitly, not by package-manager magic.

Verdict

The real target of these attacks is not your code, it is developer credentials and CI tokens. The structural defence is to stop treating npm install as a harmless command: disable lifecycle scripts by default, trust the lockfile and not the latest tag, and keep publish-scoped tokens off development machines. Shai-Hulud will be back under another name next month, the attack surface is always the same.