When the Signature Is Valid and the Code Is Malware: The keyv Supply Chain Attack

On 4 August 2026, an attacker who had compromised the GitHub account of the maintainer behind keyv, a key value storage library with roughly 127 million weekly downloads, pushed a credential stealer directly to the main branch and cut releases across the entire package family. A self propagating worm then used stolen npm credentials to automatically backdoor every other package that maintainer had publish rights to. Within hours the campaign had reached over 1,300 package versions representing a combined two billion monthly downloads, including widely used libraries such as cacheable, flat-cache, and file-entry-cache.

Every Cryptographic Check Passed

The detail that should concern security teams most is not the scale. The poisoned packages carried valid npm provenance signed by GitHub Actions. They genuinely were built by that repository, in that workflow, on that commit. The attestation was correct. The code was malware. This was the second npm compromise in three months to ship malware with legitimate attestations.

Software supply chain security has spent several years converging on signing and provenance as the answer to package tampering. That work remains valuable, but this incident marks its limit clearly. Provenance proves a package came from where it claims to have come from. It says nothing about whether the account behind that origin was under the control of its rightful owner at build time. When the compromise happens upstream of the build, the signature certifies the malware.

The payload added a preinstall hook that downloaded a runtime and ran an obfuscated stealer targeting npm tokens, GitHub CLI tokens, AWS credentials, Vault tokens, Kubernetes configs, and crypto wallets. Those stolen credentials were then used to publish further compromised packages, which is what turned a single account takeover into a self spreading campaign.

Why This Reaches Organisations That Write No Code

The instinct in most SMEs and asset management firms is that this is a developer problem. It is not, for two reasons.

First, dependencies are transitive. When a developer installs one package, the packages that package depends on are installed automatically. Components nobody selected end up in the build, which is precisely why a compromise of one caching library propagated into the software supply chains of numerous organisations that had never heard of it.

Second, and more relevant if you buy rather than build: your suppliers have this exposure. The client portal, the booking system, the internal tool built by an agency two years ago, all of it likely depends on npm packages. A credential stealer running in a supplier’s CI environment reaches the cloud credentials and deployment tokens for systems holding your data. Your third party risk questionnaire almost certainly does not ask about this.

What To Do

If you build software, the immediate action is to establish whether any affected version was pulled and, critically, whether it could have executed. The malicious versions were published in a bounded window on 4 August; a version predating that window is not part of the campaign, so confirm the specific version rather than the package name. Where lifecycle scripts are disabled by default, a package that was pulled but never executed represents materially lower risk. On any confirmed execution, rotate npm tokens, cloud credentials, and every secret reachable from that environment, and review recent publish activity on your own packages.

Structurally, the lesson is that trust decisions cannot rest on signatures alone. Pin dependencies to exact versions rather than ranges, disable install scripts by default in both developer and CI environments, and hold new package versions in a staging period before they reach builds. Most of the damage in campaigns of this type occurs in the first hours after publication, so even a short delay removes the majority of the exposure.

For organisations that buy rather than build, this belongs in your supplier assurance process now: ask whether they were affected by the 4 August npm campaign, how they determine which open source components are in their products, and what their process is for rotating credentials after a suspected build system compromise. Vague reassurance is not an answer.

Key message: A compromised maintainer account turned hundreds of trusted npm packages into credential stealers, and the malicious releases carried cryptographically valid provenance. Signing proves origin, not integrity of intent, and cannot be the sole basis for trusting a dependency. Verify specific versions rather than package names, disable install scripts, delay adoption of new releases, and extend the question to the suppliers who build software on your behalf.