Keyv npm Worm: What JavaScript Teams Should Do Now

The Keyv incident is an incident-response problem, not a routine dependency update.

On August 4, attackers published keyv@6.0.0 after compromising the project's source and release path. The package ran a credential-stealing worm during installation, then used exposed publishing credentials to spread into other npm packages. The affected Keyv version has since disappeared from the public npm registry, where 5.6.0 was again tagged latest when this analysis was prepared. That rollback reduces new exposure. It does not clean developer laptops, CI runners, caches, published artifacts, or stolen credentials.

OpenSourceChoice verdict: first prove whether an affected package was resolved and whether its install code ran. If it did—or if a compromised source checkout was opened in a tool that executed repository hooks—treat the host and every reachable secret as compromised. Isolate it, revoke credentials from a clean device, audit unauthorized package and repository activity, and rebuild from a trusted image. Do not make a rushed architectural migration from Keyv merely because its release chain was compromised. Teams that only need local memory caching should compare lru-cache; Redis-only applications should compare the official redis client; multi-backend users can hold a reviewed, known-good Keyv version while requiring clear recovery evidence before any future upgrade.

Methodology: This is a researched security and adoption analysis based on the npm registry, GitHub repository and advisory state, OSV, npm and GitHub documentation, and original incident research observed on August 5, 2026. OpenSourceChoice did not install the malicious packages, execute the payload, perform malware reverse engineering, or claim a complete victim count. Repository files were inspected read-only. Campaign totals remain point-in-time estimates from security researchers, not independently reproduced measurements.

Why this matters now

This was not a single suspicious tarball caught before release.

• keyv@6.0.0 was published on August 4 with valid GitHub Actions provenance after the attacker changed the legitimate source repository and used its release workflow.
• The package's install-time code sought credentials and publishing access, allowing the campaign to propagate across unrelated package namespaces.
• Aikido, Socket, StepSecurity, and Wiz independently documented the campaign while maintaining evolving affected-version lists.
• GitHub published malware advisory GHSA-3p9h-f68w-m6fx, and OSV mapped the event to MAL-2026-11524.
• The incident generated substantial discussion on Hacker News and in several security, npm, self-hosting, and project communities. An Unsloth maintainer, for example, publicly checked the older transitive versions used by that project against the incident list.

Those are independent technical and community signals, not one viral post. Product Hunt and XDA did not add useful primary evidence for this decision, and social posts are not used here to establish affected versions or payload behavior.

The timing matters because the obvious signal—npm install failing to find version 6.0.0—can create false reassurance. Removal prevents an ordinary fresh resolution from the public registry. It cannot revoke a downloaded tarball, delete a package-manager cache, change a lockfile, erase a container layer, invalidate a CI artifact, or rotate a token already copied by an attacker.

What is verified now

The current state is less tidy than “bad version removed, incident over.”

The registry snapshot for keyv@5.6.0 declares the MIT license, has no lifecycle install script in its published manifest, and depends on @keyv/serialize. OSV returned no advisory for that exact Keyv version when checked. Those observations establish a useful known-good comparison point; they do not certify every transitive dependency or local artifact.

The public repository's SECURITY.md directs reporters to open a public issue with a security label before a private advisory is created. That process is weak for an active credential-stealing compromise because early public details can help an attacker and because account compromise calls the normal maintainer path into question. This process risk belongs in any decision to resume upgrades.

What the attack changed about the trust model

Keyv is a small, useful abstraction: it exposes a consistent key-value API and supports adapters for Redis, SQLite, PostgreSQL, MongoDB, and other stores. Applications use it for caches, sessions, queues, rate limits, and other state where a backend can change without rewriting every call site.

The worm did not demonstrate that this architecture is fundamentally unsafe. It demonstrated that package trust crosses more systems than most dependency reviews acknowledge:

Maintainer account -> repository -> workflow -> registry -> lockfile -> installer
                     |                                      |
                     +-> editor/agent hooks                 +-> developer and CI secrets

A valid provenance statement can establish that a package was built by the declared workflow from a specific repository commit. It does not prove that the commit was authorized, that the maintainer account was healthy, or that the code was benign. In this incident, source and release infrastructure were part of the compromised path, so provenance faithfully described the origin of a malicious artifact.

That is not an argument against provenance. It is an argument for combining it with protected branches, reviewed release changes, isolated builders, short-lived credentials, environment approval, and install-time policy.

First prove exposure

Do not begin with npm audit alone. A malware package may be removed, an advisory may arrive after installation, and the current node_modules tree may differ from the tree that ran in yesterday's CI job.

1. Search dependency state

From each JavaScript repository, inspect the installed tree and why packages are present:

npm ls keyv flat-cache file-entry-cache cacheable-request cacheable cache-manager --all
npm explain keyv

Then search every lockfile rather than assuming the current install is historical truth:

rg -n 'keyv|flat-cache|file-entry-cache|cacheable-request|cache-manager|@cacheable/' package-lock.json pnpm-lock.yaml yarn.lock

Compare each resolved name@version with the current GitHub advisory and Wiz's maintained CSV. Do not flag every occurrence of keyv; older versions may be unaffected. Do not clear caches yet, because the lockfile, cached tarball digest, CI log, and artifact manifest may be needed to establish what actually ran.

2. Reconstruct execution

For each affected resolution, determine:

• when the lockfile changed;
• which developer, CI, preview, release, and deployment jobs installed it;
• whether lifecycle scripts were allowed;
• whether the package came from the public registry, a mirror, or an internal cache;
• which filesystem paths, environment variables, credential helpers, metadata services, and network destinations the process could reach;
• whether a current compromised source checkout was opened by VS Code, Claude Code, or another tool capable of running repository-defined startup hooks.

An affected version in a lockfile proves that the dependency graph selected it. It does not by itself prove that the malicious script executed. Conversely, a clean tree today does not disprove execution yesterday.

3. Classify the result

“We do not see suspicious cloud activity” is not enough to choose the first row. Attackers may use stolen credentials later, sell them, or create persistence where normal application dashboards do not show it.

If execution occurred, downgrade is not remediation

Deleting node_modules or pinning Keyv to 5.6.0 removes one delivery path. It does not invalidate stolen access.

Use this sequence:

1. Isolate the affected host or runner. Preserve relevant logs and dependency evidence. Stop it from reaching production services, package registries, source control, and cloud control planes.
2. Revoke from a clean device. Start with npm automation and publishing tokens, GitHub tokens and sessions, CI secrets, cloud access keys, Kubernetes credentials, Vault tokens, SSH keys, signing keys, and deployment credentials reachable from the process.
3. Audit unauthorized changes. Review npm package versions, dist-tags, new maintainers, GitHub repositories, workflows, deploy keys, personal access tokens, organization applications, cloud identities, and infrastructure changes.
4. Rebuild; do not merely clean. Replace developer hosts and runners from trusted media or known-good immutable images. Recreate package caches and container layers after preserving evidence.
5. Reissue secrets with narrower scope. Prefer short-lived workload identity and trusted publishing over long-lived shared tokens. Separate install jobs from publish and deploy environments.
6. Validate downstream artifacts. Rebuild applications from verified lockfiles and clean caches, then compare dependency manifests and attestations before redeployment.

The main cost is not the open-source library or a replacement cache. It is inventory, containment, secret rotation, audit review, clean rebuilds, and confidence in every artifact produced during the exposure window.

Controls that would have reduced the blast radius

Make install scripts exceptional

npm 12 makes dependency lifecycle scripts opt-in through allowScripts. A team should maintain a reviewed allowlist, fail closed for undeclared scripts, and periodically prove that each allowed package still needs installation code.

This control directly addresses the Keyv delivery mechanism. It is not a universal malware shield: harmful code can execute later when an imported package runs, and repository startup hooks sit outside npm's lifecycle-script policy.

Add a release-age buffer

npm's min-release-age policy can delay newly published versions. A 48-hour or multi-day buffer would have prevented an ordinary resolver from immediately selecting 6.0.0 while researchers and the registry reacted.

The trade-off is delayed security fixes. Define a reviewed exception path for urgent releases rather than disabling the buffer across the organization. A buffer buys investigation time; it does not establish quality.

Keep builds deterministic and disposable

Use lockfiles and npm ci, immutable runner images, clean per-job package caches, and a recorded SBOM. Do not mount a developer home directory, SSH agent, cloud profile, or production secrets into a dependency-install job.

Network egress should be allowlisted where practical. A build that only needs the package registry and approved source hosts should not have unrestricted access to arbitrary external endpoints or cloud metadata.

Separate publishing from testing

Trusted publishing with OIDC removes long-lived npm tokens from general CI storage. Combine it with a protected release environment, human approval, branch protection, pinned third-party actions, and a job that cannot run on arbitrary pull-request code.

OIDC does not solve compromised source by itself. The release identity still needs an authorization boundary that the attacker cannot cross merely by pushing a commit.

Treat repository automation as executable code

Review .vscode, .devcontainer, agent configuration, package scripts, Git hooks, and workflow changes with the same scrutiny as application code. Disable automatic folder tasks and repository-defined agent hooks in untrusted checkouts. Inspect a new repository in a non-executing viewer or disposable environment before opening it in a feature-rich IDE.

Should teams keep using Keyv?

The answer depends on the abstraction you actually need and on the project's recovery—not on panic.

Keyv's MIT license permits commercial use, modification, and redistribution subject to the license notice. It has no required hosted service and creates little vendor lock-in at the API layer. Its value is portability across storage adapters. Its cost is the extra abstraction, adapter lifecycle, dependency review, and now a higher bar for restoring release trust.

Before production use resumes, require all of the following:

• a maintainer-authored incident report with a bounded timeline and affected assets;
• confirmation that compromised accounts, tokens, workflows, hooks, and source files were removed;
• a clean default branch whose relevant recovery changes can be independently reviewed;
• a newly published npm version tied to the clean source and a documented release process;
• an updated advisory that identifies the safe version;
• evidence of stronger maintainer, branch, and publishing controls;
• independent scanners agreeing on the new artifact and your own install policy blocking unexpected scripts.

A Git tag alone is not sufficient, especially when the registry does not serve a matching recovery release.

Alternatives to evaluate in parallel

Do not replace Keyv with another package solely because it has more stars or a recent release. Verify that alternative's current license, supported Node version, lifecycle scripts, dependency tree, security policy, maintenance activity, and release controls. A direct Redis client improves transparency only if the application does not need Keyv's portability.

A measurable recovery and adoption plan

Use these gates before declaring the incident closed or approving the next Keyv release:

1. Inventory coverage: 100% of JavaScript repositories, CI workflows, runners, base images, registries, caches, and deploy artifacts have an owner and recorded search result.
2. Dependency evidence: zero affected name@version pairs remain in deployable lockfiles, SBOMs, images, mirrors, or caches.
3. Execution scope: every affected install or source checkout maps to a specific host, time window, network boundary, and reachable credential set.
4. Credential recovery: all potentially exposed credentials are revoked—not merely rotated in place—and replacement credentials have shorter life and narrower scope.
5. Artifact recovery: production builds are reproduced from clean images and caches; hashes, SBOMs, and provenance point to the reviewed dependency graph.
6. Install policy: dependency lifecycle scripts fail closed, allowed scripts have named owners, and a release-age buffer is enforced with an auditable exception process.
7. Release isolation: package install, test, publish, and deploy permissions are separated; production credentials cannot be read by general build jobs.
8. Project trust: any new Keyv version passes the recovery requirements above and a staged canary with no unexpected files, scripts, network access, or dependency drift.
9. Exit test: one representative service can switch to its parallel alternative or roll back within the team's recovery-time objective.

OpenSourceChoice assessment

• Best for: existing teams that need one key-value API across multiple adapters and can hold a reviewed version while the project proves recovery.
• Not for: new deployments that only need an in-process cache or one Redis backend, and organizations unable to isolate dependency installs from valuable credentials.
• Why now: the August 4 worm used a legitimate repository and release path, spread beyond Keyv, and left historical artifacts relevant after registry removal.
• Real cost: incident investigation and dependency governance, not Keyv's license fee.
• Main risk: stolen publishing and cloud credentials can outlive the malicious package that collected them.
• Production gate: clean rebuilds, revoked credentials, zero affected artifacts, strict install policy, and a transparent upstream recovery release.
• Parallel alternative: lru-cache for process-local state or the official redis client for a Redis-specific architecture.
• Recommendation: do not install keyv@6.0.0, do not trust the current repository branch merely because it is official, and do not accept a future release until source, account, workflow, advisory, and artifact evidence agree.

Sources

Primary project, registry, and advisory sources:

• Malware in keyv — GitHub Advisory Database; published and updated August 4, 2026; affects keyv@6.0.0; no patched version listed when accessed August 5.
• MAL-2026-11524 — OSV; modified August 5, 2026; machine-readable alias and affected-version record for the Keyv malware package.
• keyv registry record — npm registry; current versions, publish times, and latest dist-tag observed August 5, 2026.
• keyv 5.6.0 manifest — npm registry; known-good comparison manifest, license, dependencies, and scripts observed August 5, 2026.
• Keyv repository — official source repository; activity, license, default branch, issues, pull requests, and tags observed August 5, 2026.
• Urgent repository and package compromise report — Keyv issue 2051; opened August 4, 2026; public incident and repository-state discussion observed August 5.
• Keyv security policy — official reporting process observed August 5, 2026.
• Keyv documentation — official API, storage adapters, serialization, and installation documentation accessed August 5, 2026.

Original incident research and maintained indicators:

• Keyv and friends compromised in npm supply chain attack — Aikido Security; published and updated August 4, 2026; initial compromise, propagation, and affected-package research.
• Popular npm packages in the Keyv and Cacheable namespaces compromised — Socket; August 4, 2026; package behavior, persistence paths, and response guidance.
• ChainDrop npm worm — StepSecurity; published and updated August 4, 2026; propagation and valid-provenance analysis.
• Keyv and Cacheable npm supply-chain attack — Wiz Research; published and updated August 4, 2026; campaign timeline and point-in-time scope.
• Maintained Keyv campaign IOC list — Wiz Research; current affected package-version CSV accessed August 5, 2026.

Defensive controls and alternative evaluation:

• npm install-time security and token deprecations — GitHub and npm; July 8, 2026; npm 12 lifecycle-script allowlisting and publishing changes.
• npm install documentation — npm CLI documentation; allowScripts, strict allowlisting, and release-age controls accessed August 5, 2026.
• npm ci documentation — npm CLI documentation; lockfile-based clean installation behavior accessed August 5, 2026.
• Using artifact attestations — GitHub documentation; provenance purpose and verification accessed August 5, 2026.
• lru-cache repository — official source; current release, runtime scope, license, and maintenance observed August 5, 2026.
• Node Redis repository — official source; current client scope, release, license, and maintenance observed August 5, 2026.

Trend and independent community signals:

• Keyv incident discussion — Hacker News; August 4, 2026; independent developer-interest signal, not technical evidence.
• Unsloth not affected by the Keyv incident — Unsloth community; August 4, 2026; example of an upstream transitive-version check and broader ecosystem concern.
• Keyv supply-chain discussion — r/cybersecurity; August 4, 2026; independent practitioner-interest signal, not primary forensic evidence.

All adoption recommendations, risk classifications, and trade-off conclusions are OpenSourceChoice editorial analysis. Researcher package totals and payload descriptions are attributed to their original investigations and remain subject to change as the campaign is analyzed.