A trusted account, not a bad line of code
The fastest way to compromise thousands of computers is not to write clever malware. It is to take over an account that already has permission to publish trusted code, and let other people's automated tools do the rest. That is roughly what happened on August 4, 2026, when attackers seized the GitHub account of the developer who maintains keyv, a small caching library used across the Node Package Manager (npm) ecosystem with roughly 127 million weekly downloads.
The same account also controlled cache-manager, cacheable-request, and several other caching utilities published under the same maintainer's namespace. Because the attackers had legitimate publishing rights, they didn't need to trick anyone into approving a pull request. They pushed a malicious commit straight to keyv's main branch and cut a new release, version 6.0.0, within minutes. The automated checks that developers rely on to catch bad releases all passed, because those checks confirm that a release came from the right build pipeline, not that its contents are safe. The poisoned release carried valid OpenID Connect and Supply-chain Levels for Software Artifacts (SLSA) provenance signatures, the same cryptographic assurances developers are told to look for as proof a package can be trusted.
How the worm actually spreads
The malicious release added two new files, setup.mjs and Math_Symbol.js, and a preinstall instruction that ran setup.mjs the moment someone installed the package. That script checked for the Bun JavaScript runtime, downloaded a legitimate copy of Bun 1.3.13 from GitHub if it wasn't already present, and handed off to a compiled payload of roughly 710 kilobytes.
Researchers at Wiz and JFrog Security Research describe the payload as a variant of a malware family known as Mini Shai-Hulud, built on code that circulated in an earlier 2026 wave of npm attacks. It goes after a long list of credentials: GitHub, npm, and cloud provider keys for Amazon Web Services, Google Cloud, Microsoft Azure, Alibaba Cloud, and Tencent Cloud; secrets from Jenkins, Argo CD, and Harbor build systems; Kubernetes configuration files; database connection strings; SSH private keys; cryptocurrency wallets on Solana and Monero; and API tokens for AI coding tools including Claude, OpenAI's Codex, Cursor, and Gemini. A newer detail researchers flagged in this wave is that the malware fetches its command-and-control domains from an Ethereum smart contract rather than a fixed server address, which makes the infrastructure harder to take down by simply blocking a domain.
Once it has stolen npm publishing tokens, including any with two-factor authentication bypass and write permissions, the malware uses them to push infected versions of whatever other packages the victim maintains, which is how a single compromised account turned into an ecosystem-wide worm. It also modifies GitHub Actions workflows to serialize and exfiltrate a repository's stored secrets.
Why it specifically targeted developer tools
One detail stands out from prior npm supply chain incidents: the compromised keyv repository included a .claude/settings.json file with a SessionStart hook pointing to a setup script, plus a VS Code tasks configuration set to run automatically when a folder opens. Both are mechanisms meant to help these tools automate routine setup work, repurposed here to try to get code running the moment a developer opened the infected project.
The mitigating factor is that both tools have workspace trust protections. VS Code does not run automatic tasks in a workspace it doesn't already trust, and Claude Code applies the same trust boundary to repository-level settings. So this particular persistence path required a developer to have already trusted the workspace, rather than firing on a bare git clone. Still, researchers flagged it as a sign that supply chain attackers are now deliberately building hooks aimed at AI coding assistants and editors, not just at continuous integration pipelines.
Nobody agrees yet on exactly how big this is
Because the worm was still actively spreading when researchers started counting, published scope estimates differ depending on when the snapshot was taken. Security firm SafeDep's early check found 353 poisoned versions across 79 package names, but a broader pass put the figure at 1,684 versions across 420 packages tied to nine different npm organizations, with the worm hopping between organizations roughly every two to seven minutes and completing that cross-organization spread in about half an hour. JFrog separately counted more than 428 packages and over 1,700 poisoned versions. Other trackers following the same incident cited totals as high as 860-plus packages once every affected dependency was counted, representing a combined download volume in the billions per month across the family of packages involved. Treat any of these single numbers as a moving snapshot rather than a final count.
As of when researchers published their write-ups, no public statement had appeared from the keyv maintainer, npm, or GitHub addressing the incident directly.
What this means in practice
If your project uses keyv, cache-manager, cacheable-request, or @cacheable/utils, check your lockfile for the affected versions (keyv 6.0.0, cache-manager 7.2.10, cacheable-request 13.0.20, and @cacheable/utils 2.5.1) and look for a stray node_modules/keyv/Math_Symbol.js file. npm 12 and later disable preinstall scripts by default, which blocks the simplest version of this attack, but don't treat that setting as complete protection: the worm also spread through stolen publish tokens and modified GitHub Actions workflows that don't depend on preinstall scripts running at all.
If you find evidence a bad version actually ran, researchers are consistent on one point: don't just delete the package and move on. Rebuild the affected machine or CI runner from a clean image, and rotate every credential it had access to, including cloud keys, GitHub and npm tokens, SSH keys, and Kubernetes configuration. A worm built to harvest and reuse tokens on contact is not something you can be confident you've fully removed by inspection alone.
