How to Secure Your npm Packages After the keyv Attack

Key Takeaways

• On August 4, 2026, an attacker hijacked the GitHub account of the maintainer behind keyv and cacheable and pushed malicious versions of nine core npm packages, which then spread to hundreds of downstream packages.
• The malicious code was a credential-stealing dropper that harvested npm, GitHub, AWS, and HashiCorp Vault secrets and exfiltrated them using an Ethereum smart contract to hide its command-and-control infrastructure.
• This is the third wave of the same "Shai-Hulud" malware lineage in 2026, following earlier compromises on PyPI and in the @antv npm ecosystem.
• The attack is a textbook example of a malicious npm package incident: a validly signed release from a real maintainer account that was, underneath, fully compromised.
• Teams relying on a vetted library source rather than the public registry directly were structurally protected - this is the same model behind Echo Libraries.

What happened: the keyv and cacheable npm attack

At around 9:00 UTC on August 4, 2026, an attacker used a compromised GitHub account to push malicious commits to the keyv repository's main branch, then cut a new release. Within minutes, the same payload appeared across eight more packages from the same maintainer, including cache-manager, cacheable-request, and @cacheable/utils.

Together, these packages represent over two billion combined monthly downloads. The malware carried its own logic for republishing itself under any npm identity it could validate, turning a single compromised account into an incident touching anywhere from roughly 400 to over 2,200 packages, depending on the tracker - a scale still climbing as researchers investigate.

This kind of self-propagating supply chain attack is exactly why provenance alone isn't a safety guarantee: a compromised account still produces a release that's validly signed and passes every routine check.

Inside the malware: what the payload actually did

Each affected package shipped two new files - setup.mjs and Math_Symbol.js - plus a preinstall entry added to package.json, so the payload ran automatically the moment someone typed npm install, before any code was imported into an application.

Once triggered, the malware:

• Harvested credentials from .npmrc, GitHub tokens, AWS keys, Kubernetes service account tokens, and HashiCorp Vault tokens.
• Validated stolen npm tokens in real time, so it only exfiltrated credentials that still worked.
• Self-propagated by republishing itself under any npm identity it compromised - the mechanism that let it spread far beyond the original nine packages.
• Hid its command infrastructure behind an Ethereum smart contract, letting the attacker rotate servers without touching the payload.
• Evaded detection by running through the legitimate Bun runtime instead of Node.js, avoiding any suspicious download domain.
• Targeted developer tooling directly, planting hook files in .claude/settings.json and .vscode/tasks.json that could trigger just by opening a cloned repo in an editor.

Why this is bigger than one bad release

This is the third documented wave of the same malware toolkit in 2026: the identical setup.mjs filename and Bun runtime trick were traced to an April 2026 PyPI compromise and a May 2026 attack on the @antv npm ecosystem. keyv and cacheable are simply the latest ecosystem it reached.

• It's reused infrastructure, not a new technique - the same toolkit moving across registries over months.
• Attackers are blending into normal developer traffic, using Ethereum RPC calls and legitimate download URLs so nothing looks unusual at the network layer.
• Provenance proves who published a package, not that their environment was trustworthy. A maintainer's account can be fully compromised while every signature still checks out.

Why Echo customers were never affected

None of this reached Echo Libraries customers, and the reason isn't luck - the compromised versions were never available to pull in the first place.

Most teams point their package manager straight at the public npm or PyPI registry, so a malicious version becomes installable the moment it's published - often within minutes of a compromised account cutting a release. That publish-to-install window is exactly what this attack exploited to spread from nine packages to hundreds.

Echo Libraries removes that window by sitting between your pipeline and the public registry, so nothing reaches you without clearing several layers first:

• Verified builds from source. For the newest and most popular packages, Echo builds directly from verified source rather than mirroring whatever's published upstream - the same category keyv and cacheable fall into given their download volume.
• Malware and greyware scanning before promotion. Every package is sandboxed and analyzed for malicious behavior and install-time scripts like the preinstall hook this attack relied on, before it's ever promoted into the catalog.
• Cooldown periods. New releases sit for a defined window before becoming available, giving scanners time to flag exactly this kind of fast-moving worm.
• Maintainer and source health monitoring. Echo watches for drift in author identity, release cadence, and behavior - the kind of signal a hijacked account and a sudden release would trip.
• Automatic patching, with access restricted until a fix exists. When a critical or high CVE turns up in a version teams already run, Echo backports a fix rather than waiting on the upstream maintainer, and restricts access to the unpatched version in the meantime.

That combination is what makes a package genuinely hardened - an npm package or PyPI package built from verified source, continuously monitored for maintainer drift, and automatically remediated as new vulnerabilities and malware surface, with no change needed to the package name, version, or install command your team already uses.

Teams on Echo Libraries never had the compromised keyv or cacheable versions available to install at all. It's the same protection model behind the npm supply chain attacks breakdown and how to protect against software supply chain attacks.

What to do if you're affected

If your project depends on any of the nine core packages, treat it as a potential compromise until verified otherwise:

1. Check installed versions against lockfiles for keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache, cacheable, file-entry-cache, @cacheable/memory, and @cacheable/node-cache.
2. Check for persistence artifacts before rotating credentials, then rotate npm, GitHub, AWS, Kubernetes, database, and Vault credentials in that order.
3. Downgrade to a confirmed clean version and pin it rather than tracking latest.
4. Rebuild affected systems rather than relying on package removal alone.
5. Upgrade to npm 12 or newer, or install with --ignore-scripts, since npm 12 blocks unapproved lifecycle scripts by default.

FAQ

What made the keyv and cacheable npm attack spread so fast?

The malware republished itself automatically under any npm account it compromised. That self-propagation logic turned a single hijacked maintainer account into an incident touching hundreds of packages within hours, rather than staying contained to the nine packages that maintainer directly controlled.

Is this the same malware as previous Shai-Hulud attacks?

Yes. Researchers traced identical hook files, the same setup.mjs filename, and the same Bun runtime version to an April 2026 PyPI compromise and a May 2026 attack on the @antv npm ecosystem - the same toolkit reused across registries, not a new variant.

Does a validly signed npm package mean it's safe to install?

No. A valid signature only confirms who published the release, not that their account was trustworthy at the time. This attack came from a real maintainer's account that was fully compromised, so every malicious version was signed like a legitimate one.

Do I need to change my dependency files to use Echo Libraries?

No. Echo Libraries mirrors the same package names, versions, and install commands you already use. You point your existing package manager at Echo's repository instead of the public one, and the rest of your workflow stays the same.

What makes a hardened npm package or hardened PyPI package different from a normal one?

A hardened package is vetted before it's ever available to install - verified-source builds, malware scanning, and a cooldown window - rather than scanned only after it's in your environment. It stays current too: critical and high CVEs are patched on the version you run, and unpatched versions are restricted until a fix exists.