Keyv npm Supply Chain Attack Hits 2 Billion Installs

The Keyv npm supply chain attack compromised a single GitHub maintainer account and used it to push a credential-stealing worm into hundreds of widely used caching packages. By August 5, trackers put the count at 868 packages and 1,381 versions, spanning a combined 2 billion-plus monthly installs — the largest software supply-chain incident DIESEC has tracked so far in 2026.

What Happened

On August 4, 2026, attackers compromised the GitHub account of “Jaredwray,” maintainer of keyv, a key-value storage library with roughly 127 million weekly npm downloads. This is not an isolated package: the same maintainer account also controls cacheable, cache-manager, cacheable-request, flat-cache, file-entry-cache, and several other caching utilities used across the Node.js ecosystem. The attacker pushed malicious files directly to the main branch and immediately cut a new release: [email protected] plus ten related package releases, each carrying a hidden preinstall script.

That script launches a roughly 727KB obfuscated payload — a descendant of the “Mini Shai-Hulud” malware family previously associated with TeamPCP and copycat actors — that harvests GitHub tokens, AWS/Azure/GCP credentials, private SSH keys, and database connection strings from any machine that runs npm install. Because npm executes lifecycle scripts like preinstall automatically by default, no developer action beyond a routine install was required to trigger it. Within roughly 30 minutes the worm spread across the shared maintainer’s package family; independent trackers reported figures ranging from a confirmed floor of 353 poisoned versions across 79 package names (SafeDep) to a broader estimate of 868 packages / 1,381 versions (Aikido).

A distinctive feature separates this from prior 2026 npm incidents: the payload plants persistence hooks directly inside developer tooling. Researchers found a Claude Code session hook and a VS Code task configured to execute when a developer opens and trusts the affected workspace — meaning the attack specifically targets the “trusted workspace” assumption AI coding assistants and IDEs rely on.

Why It Matters

Five packages have confirmed malicious versions with known-bad version numbers published (keyv, cache-manager, cacheable-request, @cacheable/utils, flat-cache); four more from the same maintainer (cacheable, file-entry-cache, @cacheable/memory, @cacheable/node-cache) are confirmed affected but without a published bad-version number yet, meaning teams cannot simply “check the changelog” to know if they were hit. For German Mittelstand organizations, the exposure is close to universal: caching utilities of this kind sit quietly inside the dependency tree of the vast majority of Node.js backends, whether built in-house or via frameworks like Express or NestJS — few teams will have deliberately chosen “keyv” but many will have inherited it three or four dependency layers down.

The Claude Code and VS Code persistence mechanism raises the stakes further. This is the point where DIESEC’s 2026 software-supply-chain arc and its AI-coding-assistant attack-surface arc (TrapDoor, May 26; Miasma, Jun 4/9) converge directly: attackers are no longer just poisoning packages, they are poisoning the developer tooling that inspects and remediates those packages.

What You Should Do Now

1. Audit package-lock.json / yarn.lock for keyv, cache-manager, cacheable-request, @cacheable/utils, flat-cache, cacheable, file-entry-cache, @cacheable/memory, and @cacheable/node-cache. Pin the four with confirmed clean versions to [email protected], [email protected], [email protected], and [email protected] via a package.json overrides block.
2. Verify: check whether any environment ran npm install against these packages on or after August 4, 2026. If so, treat that environment as potentially compromised until proven otherwise.
3. Mitigate: rebuild lockfiles with npm install --package-lock-only --ignore-scripts, delete node_modules, run npm cache clean --force, then reinstall with npm ci --ignore-scripts to prevent any lingering lifecycle script from firing.
4. Monitor: rotate every credential reachable from an affected build runner or developer workstation — GitHub personal access tokens and App tokens, cloud keys and assumed roles, Kubernetes service-account tokens, CI/CD secrets, and SSH keys. Review Claude Code and VS Code workspace-trust settings and any auto-run hooks or tasks in repositories cloned or opened since August 4.

DIESEC Perspective

This is the clearest example yet of a pattern we flagged with TrapDoor in May: attackers are treating AI coding assistants and IDEs not as tools to avoid, but as an additional persistence layer to exploit — because a “trusted workspace” is itself a privileged execution context most security teams have not yet modeled as one.

Not sure whether your development pipeline still has an exposed lifecycle-script execution path or an unreviewed Claude Code/VS Code trust setting from this incident? Contact DIESEC for a rapid software supply-chain exposure assessment.

Sources: Wiz | The Hacker News
Published: 2026-08-06 | Category: Supply Chain Security | ~4 min read