Notifications
Clear all
Topic starter
18/08/2026 2:29 pm
TL;DR: The keyv and cacheable npm compromise turned package installation into code execution, then used stolen npm, GitHub, cloud, Vault, and Kubernetes secrets to republish trojanized packages across a widening downstream set, according to Corgea. This is a supply-chain identity failure as much as a malware event: once install-time execution reaches secret-bearing hosts, provenance and snapshots alone do not contain the blast radius.
NHIMG editorial — based on content published by Corgea covering the keyv and cacheable npm compromise: the latest package supply-chain analysis and response guidance
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: What breaks when package installation is allowed to run arbitrary scripts?
A: The installation step becomes an execution boundary instead of a supply-chain check.
Q: Why do CI runners and developer workstations increase supply-chain identity risk?
A: They often hold the very credentials attackers want: npm tokens, GitHub context, cloud metadata access, Vault secrets, and Kubernetes service account material.
Q: How can security teams tell whether secret exposure from package installs is contained?
A: Containment is real only when exposed credentials are revoked, replacement identities are least privileged, and the build and repository estate has been searched for persistence markers.
Practitioner guidance
- Harden package lifecycle execution Disable or tightly gate install scripts for third-party dependencies, and inspect any package that adds preinstall, postinstall, or setup hooks.
- Isolate secret-bearing build environments Move npm installs away from runners and workstations that can read cloud tokens, Vault credentials, GitHub context, or Kubernetes service accounts.
- Review publisher and maintainer identities Audit who can publish to package scopes, who can approve releases, and which automation tokens can reach the registry.
What's in the full report
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Exact package and version inventory for the compromised keyv and cacheable ecosystem
- Indicator list for package-install compromise, including setup files, Bun execution traces, and Ethereum-based C2 pivots
- Expanded downstream package scope across third-party scopes such as qlik, servicetitan, onereach, and deliveroo
- Response guidance for registry proxies, CI runners, and maintainer accounts after suspected exposure
👉 Read Corgea's analysis of the keyv and cacheable npm supply-chain compromise →
Keyv and cacheable package compromise: what defenders should do now?
Explore further
18/08/2026 3:17 pm
Supply-chain identity risk is now a governance problem, not just an AppSec problem. When package installs can read live secrets and publish new versions, the real control boundary sits across IAM, PAM, CI/CD, and NHI governance. That means publisher identities, runner identities, and secret-bearing service accounts need the same lifecycle scrutiny as interactive users. Practitioners should treat package publication as an identity event, not only a release event.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why secret-bearing build hosts remain easy to miss.
A question worth separating out:
Q: Who is accountable when a compromised package publishes additional trojanized versions?
A: Accountability sits with the maintainer identity, the release automation owners, and the teams governing build secrets and publish rights. A package registry incident is not only a software event. It is a lifecycle failure across identity, release governance, and access control, so response ownership should span engineering, IAM, and platform security.
👉 Read our full editorial: Keyv and cacheable npm compromise shows supply-chain identity risk
