A cache library becomes an attack platform
Keyv is a small, unglamorous key-value storage abstraction used across the Node.js ecosystem as a caching layer for larger tools. That obscurity is exactly what made it a useful target: it is the kind of dependency few engineers ever open, let alone audit, before pulling it into a build, and it sits deep enough in the dependency tree that most teams would not recognize its name if asked, let alone flag it during a review. On August 4, 2026, version 6.0.0 was published to npm under the maintainer's account carrying a malicious preinstall script, and the compromise did not stop at that single package. A follow-on commit propagated the same payload files across all 19 workspace packages in the associated scope, staging future poisoned releases even after the initial one was flagged by researchers watching the registry in real time, a level of persistence that outlasted the first wave of takedown efforts.
The repository itself carried 3,167 stars and 199 forks, meaning a large population of developers routinely cloned it to inspect the source, a habit the attacker's second infection vector was specifically built to exploit. A cryptographically verified commit, spoofed to appear authored by github-actions[bot], planted the malicious hooks, which is a level of access, and a level of deception, that goes beyond a simple stolen npm token. Producing a verified commit under a spoofed bot identity typically requires either a compromised GitHub App installation or direct API access to the repository, neither of which is trivial to obtain.
Two ways in: install scripts and IDE auto-execution
The primary infection path followed a familiar npm supply chain pattern. A preinstall script ran node setup.mjs before any application code executed, meaning anyone who installed [email protected] directly or received it as a transitive dependency triggered the payload automatically, no user action beyond a routine install required. That alone would make this a standard, if serious, supply chain incident, the kind security teams have built tooling to catch over the past several years of npm-borne compromises.
The second path is what made this campaign different. The compromised repository contained a .claude/settings.json file with a SessionStart hook and a .vscode/tasks.json entry configured to run on folder open, meaning a developer who simply cloned the repository and opened it in Claude Code or VS Code could trigger execution without ever running npm install. Both editors gate this behavior behind a workspace trust prompt, which means the attack depended on developers clicking through a trust dialog they may not have read closely, a bet that clearly paid off often enough to matter.
What the payload actually stole
Once running, a first-stage dropper checked for the Bun JavaScript runtime, downloaded a legitimate Bun 1.3.13 build from GitHub's official repository if it was missing, executed an obfuscated second-stage payload, then deleted the runtime to reduce forensic traces. That second stage was a 727,680-byte Bun-compiled bundle using basE91 encoding with per-module alphabets, and property analysis of the code showed it targeting GitHub tokens, GitHub App installation tokens, npm publishing credentials, AWS keys pulled from local credential files, HashiCorp Vault secrets, Kubernetes configs, database credentials, and private keys.
The payload's most dangerous feature was not the theft itself but what came after it. Researchers found the code could install a watcher that reacts when a stolen token stops working, meaning a routine credential rotation by an alerted security team could trigger attacker-supplied logic rather than simply closing the hole. SafeDep specifically advised removing that persistence mechanism before rotating any exposed tokens, reversing the instinct most incident responders reach for first.
Nobody agrees on how big this was
Three separate security vendors published scanning results within hours of each other, and their numbers did not converge. SafeDep's verified count stood at 353 poisoned versions across 79 package names, with a wider estimate of 442 versions across 353 names. Aikido Security's tally ran far higher, more than 868 packages across 1,381 versions. Both figures were defensible readings of a registry that kept changing underneath them, and neither vendor was wrong so much as measuring a moving target at a different moment in its evolution.
The gap is itself the finding. npm restored earlier clean releases, including keyv 5.6.0, flat-cache 6.1.23, and cache-manager 7.2.9, as the default latest tag for at least nine packages by the evening of August 4, which means any scan run after that point undercounts the packages that were briefly compromised. SafeDep's conclusion was blunt: the registry changed too quickly to support a fixed campaign-wide list, and teams need to check exact resolved versions and lockfiles rather than lean on a dynamic package list that was already stale by the time it was published.
A pattern, not an isolated incident
Security researchers connected this campaign to the Shai-Hulud malware family on the strength of matching artifacts: the identical setup.mjs filename, the same Bun 1.3.13 download behavior, and near-identical Claude Code and VS Code hook configurations seen in an April 2026 compromise of the lightning package on PyPI. That repetition suggests a maintained toolkit being reused across ecosystems rather than a one-off campaign built and discarded after a single run, and it means the IDE auto-execution trick is now a known, reusable technique that other operators can copy rather than a one-time novelty confined to a single incident or a single package ecosystem.
It is also a direct signal about where attackers are placing their bets. AI coding assistants and their auto-execution hooks are new enough that most organizations have not yet extended their software supply chain controls to cover them, and this campaign specifically targeted that gap rather than the install-script vector security teams have spent years hardening against. Expect more campaigns to probe the same seam, since the payoff, silent code execution triggered by nothing more than opening a folder, is far higher than the cost of writing a convincing README.
What to do about it now
Pin keyv to 5.6.0 or an earlier 5.x release, and audit lockfiles across your dependency tree for keyv, cacheable, flat-cache, and file-entry-cache resolving to any version published on August 4, 2026. Do not clone the affected repository directly into an IDE without inspecting its contents first, and review your organization's workspace trust defaults for Claude Code and VS Code, since the default prompt behavior is the only control standing between a casual clone and automatic code execution.
If exposure is confirmed or suspected, remove any persistence or watcher scripts before rotating credentials, then rotate GitHub tokens, npm publishing tokens, AWS keys, and Vault secrets in that order. This incident is a useful forcing function to ask a broader question: does your software supply chain policy account for AI coding tools at all, or does it still assume the only execution path into a developer's machine runs through npm install?
