Quick summary
- The keyv/cacheable investigation is a reminder that a compromised npm dependency can spread through transitive resolution, not just direct imports. Teams need to scope exposure from build evidence and deployed artifacts.
- A package compromise can affect many repositories and releases before a direct dependency review finds it. Lockfiles and CI artifacts are essential incident evidence.
- Inventory keyv/cacheable versions in lockfiles, CI caches, and deployed images, then compare them with evolving authoritative guidance.
What happened
An npm package hijack is not only a maintainer problem. When a package sits deep in a dependency tree, ordinary builds and releases can distribute a risky artifact across services before the organization knows it is exposed.
Wiz Research says it is investigating an ongoing supply-chain attack affecting multiple keyv/cacheable npm packages. The supplied public material does not establish every affected version or behavior, so teams should validate their own retrieved artifacts rather than infer details.
Why transitive dependencies expand the blast radius
A manifest is only part of the picture. A lockfile records a resolved version at a point in time, while indirect dependencies can arrive through several branches and different repositories can resolve different releases.

The useful opening question is therefore not simply “Do we import keyv?” It is: “Which commits, build outputs, and environments resolved or executed an artifact within the advisory scope?”
Start incident response with build evidence
- Pause nonessential dependency updates while preserving an emergency patch path.
- Search lockfiles, CI caches, SBOMs where available, container images, and install logs for actual package versions.
- Map relevant repositories, builds, and releases, prioritizing systems that can access secrets or publish packages.
- Upgrade or remove flagged versions when authoritative guidance is available, then rebuild affected artifacts from a clean environment.
A lockfile change is not the end of the investigation
Pinning controls the next install; it does not identify where older artifacts ran. If a suspect build could read CI variables, publishing credentials, or other secrets, assess rotation based on the access that build actually had.
This is also a good time to review publisher access, maintainer-change controls, and alerting for critical packages. The operational goal is a verifiable exposure map, not merely a clean dependency diff.
What to monitor next
Track updates to the keyv/cacheable investigation alongside registry and maintainer advisories. Restore routine automated updates only after dependency policy, provenance checks, and publishing permissions have been reviewed.
In 5 Minutes
- Scope transitive dependencies, not only direct imports.
- Use lockfiles, CI logs, and images as incident evidence.
- Rebuild patched artifacts from a clean environment.
- Evaluate secret rotation against actual build privileges.
Sources
- Securing open source software, together
- Supply Chain Security Analysis of a 9.5M-Install VS Code Extension
- Rust Supply Chain Attack on arrayref: Significant Overlap with DPRK Campaigns
- How to Investigate GitHub PAT Compromise: Lessons From a Multi-Organization Campaign
- Closing the Blind Spot: Securing Personal Repositories in the Software Supply Chain
- keyv and cacheable npm Package Hijacked in Supply Chain Attack
Why developers should care
A package compromise can affect many repositories and releases before a direct dependency review finds it. Lockfiles and CI artifacts are essential incident evidence.
Recommended action
- 1Inventory keyv/cacheable versions in lockfiles, CI caches, and deployed images, then compare them with evolving authoritative guidance.

