The Keyv npm worm campaign highlights a familiar weakness in the modern software supply chain: a single infected dependency can spread across many projects, publishing accounts, and CI/CD environments in a very short time. According to The Hacker News, the first confirmed malicious code appeared in [email protected] on August 4, 2026, before spreading beyond the Keyv and Cacheable namespaces.
The incident is notable not only because of the number of affected packages. It also shows attackers combining multiple execution points: npm lifecycle scripts, compromised account publishing rights, CI/CD runners, developer tokens, Claude Code hooks, and Visual Studio Code task configuration.
The starting point: a lifecycle script
In the first malicious release, the [email protected] package added the node setup.mjs command to the preinstallphase. This is a sensitive position because npm can run lifecycle scripts while installing dependencies, before developers have time to inspect the package contents closely.
According to analysis cited by The Hacker News from SafeDep and Socket, the first stage checks for the presence of Bun, downloads the runtime if needed, and then hands execution to a compiled bundle. This payload can collect GitHub and npm tokens, cloud keys, Vault data, Kubernetes data, database credentials, private keys, and even information from GitHub Actions runner memory.
Why the worm could spread widely
When malware runs on a development machine or CI/CD runner, it may gain access to credentials used to publish new packages. If that account has npm publishing rights, the payload can modify, bump versions, and republish packages controlled by the account. This is the mechanism that turns credential theft into an automated distribution chain.
SafeDep confirmed 353 malicious versions across 79 package names, while its monitoring observed a broader scope of 442 versions across 353 names. Aikido later reported at least 868 packages across 1,381 versions. These figures reflect the scale of malicious artifacts on the registry; they do not necessarily equal the number of victim machines that executed the payload.
Claude Code and VS Code hooks expand the risk surface
The incident also has another noteworthy layer: the Keyv repository was observed retaining hooks for Claude Code and Visual Studio Code. The .claude/settings.json configuration contains a SessionStart hook that calls a file in the .vscodedirectory, while .vscode/tasks.json contains an environment task that runs when the folder is opened.
These hooks do not run automatically in every default environment. VS Code has workspace trust controls and usually asks the user for permission before running automatic tasks. Even so, their presence shows attackers looking for additional execution paths beyond traditional lifecycle scripts, especially as AI coding tools become more deeply integrated into development workflows.
Valid provenance is not enough to conclude safety
One important point in the campaign is that the infected Keyv release still had valid OpenID Connect and SLSA provenance because it passed through the project's official GitHub Actions workflow. That does not make the source code safe. Provenance confirms the build path and the identity of the release process, but it does not guarantee that the input content before the build was clean.
For automated dependency systems, this is the key lesson: signatures, valid workflows, and verification badges are only part of the trust chain. If credentials or the commit process are abused, the system can correctly attest to a very wrong release.
What engineering teams should do
Organizations should inspect lockfiles, CI/CD caches, and installation history to identify the exact package names and versions that were resolved, instead of relying only on the current latest tag on npm. When a registry changes quickly, a namespace-level blocklist can miss malicious versions or incorrectly flag clean releases.
For workstations or runners that installed an affected version, the environment should be treated as credential-exposed. However, SafeDep warns that the malware's token-revocation watcher must be removed before rotating keys, because revoke operations may trigger a handler planted by the attacker. Only then should teams rotate GitHub, npm, cloud, SSH/private keys, and related CI/CD secrets.
For long-term prevention, development teams should restrict unnecessary lifecycle scripts, use newer npm versions with policies that block unapproved dependency scripts, separate publishing rights according to least privilege, monitor release workflow anomalies, and review coding-tool workspace configuration before trusting a repository.
Conclusion
The Keyv npm worm is a reminder that the software supply chain is not attacked only through the main application source code. Risk can sit inside a small dependency, an install script, a release workflow, CI/CD tokens, and even the tooling configuration a developer opens every day. In the fast-moving JavaScript ecosystem, response capability depends on knowing exactly which environment ran which version, with what permissions, and in what context.
VNCyberS compiled from The Hacker News, SafeDep, Socket, and Aikido
Tiếng Việt
English