The keyv npm Worm: What It Means for Your CI/CD Pipeline

On August 4, 2026, at 09:35 UTC, someone published a malicious release of the keyv npm package. Within thirty minutes it had spread, on its own, into more than 400 other packages across nine unrelated companies, stealing credentials from every environment it touched along the way. No CVE was ever assigned to it, because the vulnerability was not in any software’s code. It was in a maintainer’s compromised account, and in how much trust the npm ecosystem places in every `preinstall` script.

The one-line version: a compromised maintainer account let attackers publish a self-propagating credential-stealing worm that used your own stolen npm publish access to spread itself further, and it hid its command infrastructure inside an Ethereum smart contract specifically to defeat the network controls most companies already rely on.

What actually happened

Security researchers at Wiz, Aikido, and SafeDep independently traced the attack to a compromised maintainer account behind keyv and its related cacheable namespace. The malicious keyv@6.0.0 release, and ten related packages, carried a hidden preinstall script that ran node setup.mjs, which deployed a 727,680-byte compiled payload. SafeDep’s initial count of 353 poisoned versions across 79 package names grew as the investigation continued, eventually reaching over 1,600 poisoned versions across more than 400 package names.

The worm moved between organizations every two to seven minutes, completing its cross-organization spread in roughly half an hour. It did this by harvesting whatever npm publishing credentials it found in the environment it landed in, then using that stolen access to publish poisoned versions of packages belonging to the next organization. Wiz attributed the payload to a descendant of the "Mini" Shai-Hulud malware family, tying it to earlier supply chain campaigns.

What it actually stole

The payload was not a narrow credential grab. It targeted GitHub and npm tokens, cloud provider credentials, HashiCorp Vault secrets, Kubernetes configuration, database connection strings, and private key material, along with memory from GitHub Actions runners specifically, which is where a lot of CI/CD secrets live in plaintext for the duration of a build. In a cloud CI environment, part of the payload also queried the instance metadata endpoint at 169.254.169.254, a well-known technique for extracting temporary cloud credentials directly from the machine the build is running on, without needing them to be checked into any config file at all.

The part that should actually worry you: the C2 layer

Most supply chain malware phones home to a hardcoded domain, which is exactly why domain allowlisting and reputation monitoring are standard defenses. This worm did not do that. Researchers at Upwind found that the malware retrieves its list of command-and-control domains from an Ethereum mainnet smart contract at address `0xE1f2395ee43e45A1556EC6438a88c31B83493103`, reached through roughly 75 hardcoded public Ethereum RPC endpoints rather than a domain it controls directly.

The reason that matters: there is no C2 domain to block in the first place. Egress allowlists and domain reputation feeds never fire, because the traffic looks like a completely ordinary query to public Ethereum infrastructure, the same kind of request a legitimate blockchain application would make. A network monitoring setup built around "flag connections to known-bad domains" has nothing to flag. The realistic detection signal is behavioral: a build agent or developer laptop suddenly making Ethereum RPC calls it has no legitimate reason to make.

The AI-tooling detail worth knowing about

The compromised repository also shipped `.claude/settings.json` and `.vscode/tasks.json` files, additional execution paths that could trigger through Claude Code and VS Code’s workspace trust mechanisms. In default configurations these require the developer to actively trust the workspace first, so this is not a silent, zero-click path the way the `preinstall` script is. But it is a preview of where this category of attack is heading: as AI coding tools and editor automation get deeper hooks into what runs automatically when you open a project, the blast radius of a single compromised dependency grows with them. We covered the broader version of this risk in The Hidden Risk of AI Skills and MCP Servers if you want the full picture on what to check before installing AI agent tooling.

What to actually do about it

Whether or not you can confirm you pulled one of the specific poisoned versions, this incident is a reason to check the following across your CI/CD pipeline, not just your `package.json`:

1. Compare your lockfiles against the affected-package list. Check `package-lock.json` / `yarn.lock` / `pnpm-lock.yaml` for any of the compromised `keyv` or `cacheable` versions, directly or as a transitive dependency. A dependency you never installed yourself can still pull one in.
2. Disable install scripts you do not need. Most package managers support running installs with scripts disabled (`npm install --ignore-scripts`) or an allowlist of which packages are permitted to run them. A `preinstall` script is exactly the mechanism this worm used, and most dependencies do not actually need one.
3. Treat any environment that ran a compromised version as credential-exposed, not just infected. If a build agent or developer machine executed the malicious script, assume every secret available to that process (GitHub tokens, cloud credentials, database connection strings) was harvested, and rotate all of it. Do not rotate quietly and assume that is the end of it: some variants of this malware family specifically watch for token rotation attempts as a signal to move faster, so treat the rotation itself as something to do quickly and completely, not in a leisurely batch.
4. Restrict npm publish access with the same seriousness as production deploy access. The entire propagation mechanism depended on stolen publish credentials. Scoped tokens, mandatory 2FA for publishing, and short-lived CI tokens instead of long-lived personal access tokens all reduce what a compromised build environment can actually do with what it steals.
5. Watch for outbound traffic you cannot explain, including to legitimate infrastructure. The Ethereum RPC angle is the reminder here: "the destination is a well-known, reputable service" is not the same as "this traffic is expected from this machine." A build agent making blockchain RPC calls is unusual enough to be worth an alert on its own.

Why this is a pattern, not an isolated incident

This is not the first npm worm to use a maintainer-account compromise as its entry point, and researchers explicitly linked it to earlier campaigns in the same malware lineage. The mechanism (steal what credentials you can reach, then use them to publish more poisoned packages) turns every dependency tree into a potential propagation path, and the average project pulls in hundreds of transitive dependencies nobody on the team has ever actually reviewed. Our guide to integrating security into your CI/CD pipeline covers the broader set of controls (dependency scanning, secret scanning, pipeline hardening) that reduce how much damage an incident like this one can do, whether or not you were directly hit by this specific worm. If you have not looked at your own public-facing infrastructure recently, our free vulnerability scanner is a fifteen-second starting point.

Frequently asked questions

Was my project definitely affected if I use keyv or cacheable?

Not necessarily. Only specific versions published during the compromise window carry the malicious payload. Check your lockfile against the specific poisoned version list from a source actively tracking it, such as SafeDep or Wiz’s published advisories, rather than assuming based on the package name alone.

Does using `npm ci` instead of `npm install` protect against this?

It reduces the risk of accidentally pulling a newly poisoned version if your lockfile was generated before the compromise, since `npm ci` installs exactly what the lockfile specifies rather than resolving fresh versions. It does not help if the poisoned version is already the one pinned in your lockfile.

Why did the attackers use a smart contract instead of just registering more domains?

Domains can be seized, sinkholed, or blocked via reputation feeds once identified, and defenders have gotten fast at doing exactly that. A public blockchain has no equivalent takedown mechanism, and the traffic pattern is indistinguishable from a legitimate application querying public infrastructure, which is precisely what makes it resistant to the standard defense.

Is this related to the Vercel breach from earlier this year?

No, they are separate incidents with different root causes. The Vercel breach traced back to infostealer malware on a third-party vendor’s machine. This incident started with a compromised npm maintainer account. Both are supply chain attacks in the broad sense, but the entry point and mechanism are different.

What is the single highest-value thing a small team can do right now?

Audit whether your CI/CD pipeline runs install scripts by default, and whether your npm publish tokens are long-lived personal tokens versus short-lived, scoped CI credentials. Those two settings determine both how easily a compromised dependency can execute code in your pipeline, and how much damage it can do if it does.