An npm worm targeting credentials was released for the first time in [email protected] on August 4, 2026. From there, it spread beyond the Keyv and Cacheable namespaces into hundreds of packages across multiple organizations. The malicious release used a preinstall script to run a credential-stealing bundle inside developer and continuous integration environments.
SafeDep verified 353 poisoned versions across 79 package names in the npm registry. Its monitoring put the wider footprint at 442 versions across 353 names. Aikido later reported at least 868 packages across 1,381 versions. Neither broader total was independently reproducible from a complete public list at the reporting cutoff.
The Keyv npm worm represents one of the more significant supply chain attacks in recent memory. Let me walk through what happened, how it worked, and what you need to do if you are affected.
The Malicious Keyv Release
The first confirmed malicious release was [email protected]. It added node setup.mjs as a preinstall command and included setup.mjs and Math_Symbol.js in the package while leaving the compiled library code unchanged. Because the script executes by default during installation of the package, it becomes an effective delivery mechanism.
Stage one checks for Bun, downloads version 1.3.13 from the runtime's official GitHub releases if needed, and hands off to a 727,680-byte compiled bundle. This bundle contains the core malicious functionality.
The Keyv repository also retained separate Claude Code and Visual Studio Code hooks that can execute the payload once a user trusts the workspace or permits the project configuration. These hooks create additional execution paths beyond the npm installation route.
What the Payload Steals
SafeDep's payload analysis says the bundle is comprehensive in its data harvesting. It steals:
- GitHub tokens and credentials
- npm tokens and publishing credentials
- Cloud provider credentials
- Vault secrets
- Kubernetes credentials
- Database credentials
- Private keys
- GitHub Actions runner memory contents
The payload also installs a token-revocation watcher and carries npm publishing machinery. Socket separately decoded code for modifying, versioning, and republishing packages available to a stolen npm identity. This explains how the Keyv npm worm spread so quickly.
The Spread Beyond Keyv
The Keyv npm worm spread beyond the initial keyv package. SafeDep found the same payload under direct npm publishing accounts elsewhere in the campaign. It said automated propagation best fits the timing and whole-namespace publishing bursts.
The evidence does not show whether the worm spread solely from one stolen publishing identity or also involved separately compromised publisher credentials. The package burst therefore cannot establish how many accounts were compromised.
Not every package linked to the original maintainer was poisoned. SafeDep says the published @keyv/* adapters and the Keyv 5.x line were clean. The repository is a separate risk: a later commit staged the payload files across all 19 workspace packages, so a release cut from the still-poisoned tree would carry them.
The Changing Registry Landscape
The registry changed too quickly to support a fixed campaign-wide list of packages still tagged latest. At 5:40 p.m. India Standard Time on August 4, npm package pages showed earlier releases restored as latest for at least nine packages from SafeDep's initial set, including [email protected], [email protected], and [email protected].
The full campaign could not be independently mapped package by package. Exposure checks must use exact package names, resolved versions, and lockfiles rather than a cached list of current tags. With tags changing and some related packages remaining clean, a namespace-level blocklist risks both missing poisoned versions and treating unaffected releases as compromised.
The Claude Code and VS Code Execution Paths
The Keyv npm worm repository carries a second execution path. Its .claude/settings.json contains a SessionStart hook that calls .vscode/setup.mjs. The .vscode/tasks.json file contains an Environment Setup task with runOn: folderOpen that calls .claude/setup.mjs.
These files create a route for executing the payload from a checked-out repository. However, these do not execute without conditions in every default environment.
VS Code prevents auto-tasks in an untrusted workspace and seeks permission before executing them by default. Claude Code applies the concept of workspace trust for project settings provided by repositories.
At 5:40 p.m. IST on August 4, both hook files were still present on main. The core/keyv/package.json manifest still declared version 6.0.0, retained node setup.mjs as its preinstall command, and listed setup.mjs and Math_Symbol.js for publication.
The Provenance Problem
The poisoned Keyv release carried valid OpenID Connect and Supply-chain Levels for Software Artifacts provenance because it passed through the project's legitimate GitHub Actions release workflow. The attestation correctly identified the build process, but could not establish that the source entering it was safe.
The commit that planted the Claude Code and VS Code hooks carried a green GitHub-verified badge and named github-actions[bot] as its author. The verified badge establishes that the commit's signature was valid. SafeDep said its author field was set to github-actions[bot]. Neither fact identifies who controlled the credential that submitted it.
Together, the provenance and commit records verified the build and signing paths, but not whether the source was safe or who controlled the credential. This is a critical lesson in supply chain security: verified provenance does not mean verified safety.
What Responders Need to Do
Socket says any workstation or runner that executed an affected version should be treated as credential-exposed. This is not a situation where you can assume you are safe. If an affected Keyv npm worm version ran in your environment, assume credentials were stolen.
SafeDep advises responders to remove the malware's credential-revocation watcher before rotating exposed tokens and keys. This is critically important. Revocation is the watcher's trigger. Rotating first can run an attacker-supplied local handler. The watcher is designed to execute when credentials are revoked, potentially giving attackers a final opportunity to act.
The recommended order is:
- Remove the credential-revocation watcher
- Rotate all exposed tokens and keys
- Audit for any unauthorized activity
The npm Client Version Factor
Npm 12 does not allow unapproved dependency life cycle scripts by default. This represents a big security upgrade. Unfortunately, previous versions of npm and other installation methods which allow life cycle scripts are still exposed.
If you are using an older npm client, then you are more vulnerable to this attack. Organizations should consider updating to npm 12 or implementing other controls to block lifecycle scripts from untrusted packages.
The Connection to Previous Attacks
Semgrep documented the same Claude Code and VS Code hooks, setup.mjs filename, and Bun 1.3.13 download in an April compromise of the lightning PyPI package. Aikido places the August activity in the Shai-Hulud family.
The overlap supports a malware-family connection. It does not establish who operated the August activity. Neither the initial access path nor a named actor is known. The Keyv npm worm may be the work of the same threat actor or someone using the same tooling.
The Missing Information
Several questions remain unanswered about the Keyv npm worm. No public incident statement from the maintainer, npm, or GitHub was located at the reporting cutoff. The totals reported by SafeDep and Aikido count malicious package artifacts, not victim systems. They establish campaign scale but do not show how many machines installed or executed the payload.
Determining system-level exposure requires the exact dependency version resolved on the machine and whether its lifecycle script ran. Without this information, organizations cannot know if they were affected simply by looking at current npm tags.
Implications for Developers
Keyv npm worm is a case in point that shows risks of working within the npm ecosystem. Arbitrary code could run via preinstall scripts on install. Malicious versions of the software could be published by hacked maintainer accounts. Verified commits and provenance do not guarantee safety.
Developers need to adopt the following practices:
- Upgrade to npm version 12 or disable execution of life cycle scripts by third party packages
- Use package lock files to ensure deterministic installs
- Conduct regular audits of packages for any malicious versions
- Adopt dependency scanning within the CI/CD pipeline
- Consider package execution compromise a security breach
Wrapping It Up
Keyv npm Worm is a major attack on the supply chain where the malware spread through more than hundred npm packages stealing credentials using the malicious [email protected] package which was using the preinstall script to get the credentials.
The worm spread through npm publishing machinery, poisoning packages across multiple organizations. The Claude Code and VS Code hooks in the repository created additional execution paths.
If you executed an affected version, treat your environment as compromised. Remove the revocation watcher before rotating credentials. Update to npm 12 if possible. And audit your dependencies carefully.
The Keyv npm worm is a wake-up call for the npm ecosystem. Supply chain attacks are becoming more common and advanced. They have to be taken seriously by developers and companies.
FAQ Section
What is the Keyv npm worm?
It is a credential-stealing malware that appeared in [email protected] and spread across hundreds of npm packages. The malicious preinstall script harvests credentials from developer and CI environments.
How did the Keyv npm worm spread?
The payload includes npm publishing machinery. Once it steals credentials, it can modify, version, and republish packages available to a stolen npm identity, allowing automated propagation across the registry.
What credentials does the Keyv npm worm steal?
The payload steals GitHub tokens, npm tokens, cloud credentials, Vault secrets, Kubernetes credentials, database credentials, private keys, and GitHub Actions runner memory contents.
What should I do if I installed an affected version?
Treat the environment as credential-exposed. Remove the credential-revocation watcher before rotating any tokens or keys. All credentials need to be rotated and verified to see if there was any unauthorized activity.
Is it possible to compromise npm 12 through such an attack?
No, npm 12 is not vulnerable to unauthorized dependency lifecycle scripts attacks. Earlier versions of npm clients and other ways of installation that enable lifecycle scripts are vulnerable.
