Keyv and cacheable npm compromise shows supply-chain identity risk

At a glance

What this is: This is a supply-chain compromise of keyv and cacheable npm packages that converted install-time execution into secret theft and downstream republishing.

Why it matters: It matters because IAM, PAM, and NHI controls around build hosts, package publishers, and CI runners determine whether one poisoned dependency becomes a broader identity compromise.

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.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Corgea's analysis of the keyv and cacheable npm supply-chain compromise

Context

The npm ecosystem compromise matters because package installation is no longer just a software delivery step when preinstall hooks can execute code, reach runtime secrets, and republish artifacts through trusted pipelines. In practical terms, dependency hygiene now intersects with identity governance: the host, the maintainer account, the CI runner, and the secret store all sit in the same trust chain.

Corgea's reporting shows a small release-time change in a package ecosystem can become a credential-harvesting and republishing mechanism once install scripts are allowed to run. That is a typical failure mode for modern supply-chain attacks, where the first visible indicator is a poisoned package but the real governance gap is uncontrolled access to secrets on build and publish systems.

Key questions

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. Malicious packages can trigger code before developers notice the package is suspicious, which lets attackers stage persistence, download second-stage payloads, or begin privilege escalation inside trusted environments. Controlling lifecycle scripts is one of the clearest ways to reduce that risk.

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. If malicious package code executes there, it can harvest live credentials and use them for lateral movement or republishing. The issue is concentration of privilege on machines that routinely execute third-party code.

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. If old tokens, workflows, or runners remain active, the exposure is still live even if the original malicious package is removed.

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.

Technical breakdown

How install-time package execution becomes code execution

In npm, package lifecycle hooks such as preinstall run during dependency installation. If a malicious release adds a script entry that invokes a loader, the package manager becomes the execution vehicle before application code is even built. In this incident, the release artifacts show added setup files and a preinstall path, which means the boundary of trust moved from source code inspection to package metadata and lifecycle behavior. That matters because many security tools still focus on the final bundled files, not on the install step that creates the compromise path.

Practical implication: Treat lifecycle hooks as executable attack surface and block or inspect install scripts on untrusted packages.

Why runtime secrets on build hosts are exposed during package installs

Build hosts, developer workstations, and CI runners often hold cloud tokens, npm credentials, Vault access, GitHub context, and Kubernetes service account material in environment variables, caches, or process memory. A malicious install script can read those locations directly, and in CI it may even attach to the runner process to extract short-lived OIDC material. Ephemeral credentials are still credentials if attacker code is already executing on the host. The threat is not just theft of a token file, but live access to the identity surface of the machine running the install.

Practical implication: Separate package installation from secret-bearing contexts and remove unnecessary credentials from build and runner environments.

How wormed package releases extend compromise through publish pipelines

This attack pattern is more than theft. Once the loader captures publish-capable credentials, it can use the package owner's identity to republish modified versions or move laterally into other scoped packages. That creates a supply-chain identity problem because the publisher account, the package namespace, and the automation workflow all become part of the attacker’s control path. Provenance alone does not stop this if the build source has already been compromised, because the resulting artefact can still be built and signed through the legitimate pipeline.

Practical implication: Add identity controls around publish rights, including step-up validation, scoped tokens, and review of package namespace ownership.

Threat narrative

Attacker objective: The attacker aimed to convert trusted package installation into secret theft and ecosystem propagation through the publisher's own identity and build infrastructure.

1. Entry occurred through a trojanized npm release that executed during package installation via a preinstall hook.
2. Credential access followed when the loader harvested npm, GitHub, cloud, Vault, and runner-memory secrets from the host.
3. Escalation happened as stolen publish and identity material enabled republishing into additional package scopes and downstream versions.
4. Impact was broader ecosystem exposure, because infected packages could spread through developer machines, CI runners, and automated release pipelines.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Install scripts create a standing exception to trust assumptions that many programmes still under-estimate. A dependency can look harmless in source form while its package metadata triggers execution before build completion. The governance gap is not just malicious code, but the assumption that dependency acquisition is passive. Teams need controls that distinguish reviewable application logic from executable lifecycle behavior, especially in ecosystems where preinstall hooks still run.

Secret sprawl is the named concept this incident exposes. Secrets stored across workstations, runners, caches, and environment variables create a wide blast radius once a package executes on the host. The article’s technical details map directly to the OWASP Non-Human Identity Top 10 and to NHI lifecycle failures around rotation and offboarding. Practitioners should close the window where package installs can reach secrets at all.

Signed provenance is necessary but not sufficient when the source repository itself is compromised. Provenance attests to how an artefact was built, but it does not validate the trustworthiness of the maintainer account or source commit that drove the build. That is why identity governance must extend upstream into source control, release approvals, and token scope. The practical conclusion is to harden who can publish, not just what gets published.

CI runners and developer machines are part of the NHI attack surface. The presence of cloud tokens, GitHub credentials, npm identities, Vault material, and Kubernetes service accounts makes these systems high-value credential concentrators. If the host is compromised during install, the attacker inherits a cross-platform identity graph. Practitioners should enforce tighter separation between package execution and privileged identity material.

From our research:

• 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.
• Read more in The 52 NHI Breaches Report for additional compromise patterns that begin with exposed credentials and end with downstream propagation.

What this signals

The signal for practitioners is that dependency security and identity governance are converging. Once install-time code can touch publish tokens, cloud metadata, and runner memory, the environment needs controls that separate untrusted execution from privileged identity material. That is where the OWASP Non-Human Identity Top 10 and NIST CSF 2.0 both become relevant reference points for governance design.

Secret-bearing build surface: this is the operational boundary where package installation, CI runners, and machine credentials intersect. The practical implication is simple: if a host can install third-party code and read secrets at the same time, it is already in the blast radius. Organisations should use that boundary to redesign runner isolation, secret scoping, and publish approvals.

The longer-term signal is that provenance checks will increasingly need to sit beside identity controls, not above them. A valid build attestation cannot compensate for a compromised maintainer account or an over-privileged automation token. Practitioners should expect package ecosystems to be governed more like privileged production systems, with tighter access reviews and stronger separation between build and publish rights.

For practitioners

• 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. Focus on packages that can execute before build completion or that pull secondary runtime components during install.
• 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. Use short-lived scoped identities and remove persistent secrets from environments that process untrusted packages.
• Review publisher and maintainer identities Audit who can publish to package scopes, who can approve releases, and which automation tokens can reach the registry. Treat package namespace ownership and token scope as identity governance controls, not administrative details.
• Search for install-time compromise indicators Hunt for setup.mjs, Math_Symbol.js, bun-dl directories, and unusual access to instance metadata or runner memory during package installation. Correlate these indicators with package version ranges and any publish activity from maintainer accounts.

Key takeaways

• The compromise shows how a package registry can become an identity attack surface when install scripts execute with access to secrets and publish rights.
• The public evidence points to broad downstream spread, but the more important failure is the concentration of NHI, cloud, and CI credentials on machines that process untrusted dependencies.
• Teams should harden lifecycle hooks, isolate build secrets, and govern publisher identities with the same rigor they apply to other privileged accounts.

Key terms

• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Package Publishing Identity: The account, token, or workflow that authorises a software package release into a registry. In practice, this identity behaves like a privileged non-human identity because compromise lets an attacker publish trusted code to many downstream consumers.
• Secret-Bearing Build Surface: The collection of developer machines, CI runners, caches, and automation environments that can access credentials while processing code. It matters because any untrusted package that executes there can potentially harvest cloud keys, registry tokens, or service account material with very little friction.
• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.

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

👉 The full Corgea article covers the package-level scope, execution chain, and remediation indicators.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the controls that prevent build hosts, runners, and publish identities from becoming compromise multipliers.