Keyv and cacheable npm compromise shows supply-chain identity risk

At a glance

What this is: This is a supply-chain compromise of npm packages where install-time execution was used to steal secrets and republish trojanized versions across many downstream packages.

Why it matters: It matters because build and developer environments can expose npm, GitHub, cloud, Vault, and Kubernetes credentials during package installation, turning one compromised dependency into a wider identity and supply-chain incident.

Context

The security gap here is not just malicious code in a package. It is the overlap between package installation, trusted publishing identities, and secrets reachable from developer or CI hosts. When install scripts can run during dependency resolution, the package manager becomes an execution environment, and any readable secret on that host can become part of the attack path.

This incident also shows why supply-chain controls and identity controls cannot be managed separately. npm tokens, GitHub credentials, cloud metadata access, Vault tokens, and Kubernetes service accounts all become part of the same trust surface once hostile code executes during install. For teams running modern CI, that is an identity governance problem as much as a software integrity problem.

Key questions

Q: What fails when npm install runs attacker-controlled lifecycle scripts?

A: The failure is that package installation becomes code execution before a developer or CI workflow has a chance to inspect the package safely. If those scripts can read local files, environment variables, or live process memory, the install path becomes a secret-harvesting channel, not just a dependency fetch. That is why lifecycle-script trust has to be governed like privileged execution.

Q: Why do secret-bearing CI runners amplify supply-chain compromise?

A: Because the runner is often where cloud, GitHub, Vault, and deployment credentials are already present for the job to function. Once malicious code executes there, those secrets are exposed at the exact point where the attacker can use them to publish, persist, or move laterally through the software supply chain. Runner isolation must therefore be treated as part of identity control.

Q: What are the warning signs that a package compromise has spread through downstream scopes?

A: Look for unexpected new versions across related namespaces, repeated republishing activity from the same maintainer identity, and package-version sets that expand over time rather than stabilise. If the compromise reaches third-party scopes, you also need to watch for automation-driven publishes, unusual publish timestamps, and new artifacts that share the same payload markers under different filenames.

Q: Should teams rely on provenance alone for package trust?

A: No. Provenance tells you the release came through a valid build and signing path, but it does not prove the source was clean or the publishing identity was uncompromised. Teams need provenance plus repository controls, maintainer identity governance, secret hygiene, and install-time execution review to reduce supply-chain risk.

Technical breakdown

How install-time execution became the entry point

The compromised packages added a preinstall hook that ran setup.mjs during npm install, which turns dependency installation into code execution. The first-stage loader then fetched Bun from GitHub and used it to run a second-stage payload, widening the execution path beyond ordinary Node.js expectations. That matters because the malicious logic sat in lifecycle scripts and added files, not in the obvious application bundle, so a quick scan of dist/ could miss it.

Practical implication: Treat package lifecycle scripts as executable attack surface and inspect install-time behavior before trusting a dependency.

Why secret-bearing hosts amplified the compromise

Once the payload ran on developer workstations, CI runners, or build hosts, it could search for npm, GitHub, cloud, Vault, and Kubernetes secrets that were readable in process memory, environment variables, or local files. The incident also targeted runner memory on GitHub Actions, which means ephemeral credentials were still harvestable if the job itself was compromised. In other words, secret exposure was not a side effect; it was the payload path.

Practical implication: Assume any host that can install dependencies may also expose credentials unless secret scope and execution boundaries are tightly separated.

How the worm republished through trusted identity paths

The second stage did more than collect secrets. Public analysis shows it used stolen npm identity material and publish-related workflows to republish trojanized versions and extend the compromise into other package scopes. That is a classic identity-to-supply-chain bridge: the attacker first gains execution, then uses the compromised maintainer or automation identity to create downstream trust. Provenance still verifies in this model because the attacker is abusing the legitimate publishing flow.

Practical implication: Separate provenance validation from trust in source identity, because a clean attestation can still come from a hostile publish path.

Threat narrative

Attacker objective: The attacker’s objective was to steal usable secrets and abuse trusted publishing identities so the compromise could spread through package ecosystems and downstream development environments.

1. Entry occurred through malicious lifecycle scripts in compromised npm packages, which converted install into code execution.
2. Credential harvesting followed as the payload searched host memory, files, and environment for npm, GitHub, cloud, Vault, and Kubernetes secrets.
3. Escalation came from using stolen publishing identity and workflow access to republish trojanized package versions into broader scopes.
4. Impact was downstream propagation across many packages and exposed developer and CI environments that trusted the poisoned releases.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply-chain identity risk is now a lifecycle problem, not a registry problem. This incident works because the attacker crossed from package publication into host execution and then into publishing identity reuse. Once a package can run code during install, the real control boundary shifts from the registry to the secrets and credentials available on the host. Practitioners should treat install-time trust as part of identity governance.

Provenance can validate the build and still fail the governance test. The poisoned releases were able to carry valid-looking publishing provenance because the compromised source and workflow produced them through legitimate automation. That means attestations are necessary but not sufficient when maintainer identity, repository access, or workflow credentials are already compromised. The governance question is who can publish, not only whether a build was signed.

Secret-bearing CI runners are effectively high-value identity brokers. The article’s memory scraping and cloud-token collection show that runner isolation is only partial if jobs can still read live secrets. In this kind of incident, ephemeral credentials are not a guarantee if they are accessible during execution. Practitioners should treat build infrastructure as part of the identity perimeter, with tight scoping, short-lived access, and strong separation between build trust and secret reach.

ChainDrop-style propagation shows why package trust and third-party trust are converging. The spread into third-party npm scopes makes this a supply-chain governance issue as much as a malware event. Public and internal package inventories now need to include which external maintainer identities, package namespaces, and automation paths can publish into your environment. Teams should re-evaluate third-party package approval as an access-control problem, not a procurement checkbox.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Third-Party, B2B and Contractor Access Guide

What this signals

Supply-chain identity risk now sits at the boundary between software build trust and credential governance. Teams that only track dependency provenance will miss the real exposure if install-time execution can still reach secrets on developer or CI hosts. The control question is whether the build environment can read anything it should not be able to publish or replay.

ChainDrop is a useful named concept for this failure mode. It describes the point where a package compromise stops being a single malicious artifact and becomes an identity-enabled propagation mechanism. That distinction matters because the containment strategy has to cover maintainer accounts, automation identities, and the host secrets those identities can reach.

For practitioners

• Hunt for install-time execution paths Review package manifests and lockfiles for preinstall, install, and postinstall hooks in the affected package families, then block or quarantine any versions that execute during dependency resolution.
• Inventory exposed secret classes on build hosts Check developer workstations and CI runners for npm tokens, GitHub credentials, cloud metadata access, Vault tokens, Kubernetes service accounts, and other secrets readable during package install.
• Revoke publishing identity after suspected exposure Rotate or revoke npm, GitHub, cloud, Vault, and Kubernetes credentials from any host that installed the trojanized versions with scripts enabled, then review what those identities could publish or access.
• Treat provenance as one signal, not the finish line Keep verifying build provenance, but add source and workflow compromise checks before accepting a package as trustworthy, especially when maintainer accounts or GitHub Actions were involved.
• Scan for downstream package spread Search internal dependency inventories for the named package families and any downstream scopes that may have inherited the malicious versions, then prioritize cleanup by runtime reachability.

Key takeaways

• The keyv and cacheable compromise shows that package installation can become an execution pathway for secret theft and republishing.
• The incident spread because trusted publish identities and host-readable credentials were both available to the attacker.
• Provenance, lockfiles, and package snapshots help, but they do not replace strict control over install-time execution and credential scope.

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.
• Supply Chain Identity: The collection of credentials, tokens, workflow permissions, and publishing rights that let software move from source to deployment. In NHI terms, it is the identity layer of the pipeline, and when it is weak, compromise can propagate through legitimate automation rather than obvious malware channels.
• Runner Memory Scraping: The technique of reading process memory on a build or CI runner to extract credentials, tokens, or plaintext secrets that were never written to disk. It is effective because many pipelines inject sensitive values into runtime memory for legitimate work, creating a high-value target inside the process boundary.
• 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.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to govern machine identities, secrets, and delegated trust across modern environments.