ChainDrop npm Worm Shows Why Valid Provenance Is Not Enough | Harness Blog

Dek: A self-propagating npm worm poisoned hundreds of packages and spread through legitimate publishing workflows. The incident exposes a critical distinction for software supply chain security: build provenance can be valid even when the source entering the build is malicious.

Based on public reporting available as of August 5, 2026, at 10:19 a.m. Central Time. Package and version counts may change as researchers continue investigating.

What happened

On August 4, a self-propagating npm worm spread from packages in the widely used keyv and cacheable ecosystem into packages controlled by multiple unrelated organizations.

SafeDep confirmed 2,234 poisoned versions across 444 package names and reported that the worm reached 12 organizations in less than four hours. Four foundational affected packages—keyv, flat-cache, file-entry-cache, and cacheable-request—collectively receive approximately 1.88 billion downloads per month.

Each malicious release added an npm preinstall hook that executed before installation completed. The payload searched developer machines and CI/CD environments for GitHub, npm, cloud, HashiCorp Vault, Kubernetes, database, and other credentials. It could also inspect GitHub Actions runner memory and use stolen npm publishing access to modify and republish additional packages.

Researchers also identified persistence mechanisms involving VS Code and Claude Code project configuration. Opening an affected repository in those tools could trigger malicious code independently of a normal package installation.

One of the most important response details is counterintuitive: the malware installed a monitor that could execute an attacker-controlled command when a stolen GitHub token stopped working. Teams therefore need to locate and remove that persistence mechanism before revoking or rotating credentials.

Why this matters

ChainDrop did not rely only on unsigned artifacts or an obviously unauthorized release process.

Some malicious packages were published through legitimate GitHub Actions and npm OpenID Connect trusted-publishing workflows. Those releases retained valid SLSA provenance because the authorized build system had, in fact, produced them.

The provenance was not technically false. It accurately identified the workflow that built and published the artifact. The failure occurred earlier: malicious source or workflow inputs had already entered the trusted process. As Socket summarized, provenance attested to build integrity, not source integrity.

That distinction matters for engineering and security leaders. Signing and attestation are important controls, but they cannot independently answer several essential questions:

• Was the source change reviewed and approved?
• Did the release correspond to an expected commit, pull request, and tag?
• Were workflow files or project configuration modified unexpectedly?
• Should this dependency be allowed to execute an install script?
• Did the build behave consistently with the package’s intended purpose?
• What identities and secrets could the build runner access?

A delivery system can be cryptographically verifiable and still faithfully build malware.

The business consequences extend beyond one poisoned dependency. Credentials taken from a developer workstation or runner can create access to source repositories, registries, cloud environments, clusters, secret stores, and downstream release workflows. What starts as a dependency incident can quickly become an identity compromise, a release-integrity problem, and an organization-wide response effort.

How teams can reduce the risk of similar incidents

Teams should treat provenance as one layer in a broader evidence chain rather than as a standalone trust decision. Provenance confirms how an artifact was produced, not whether the underlying source code is trustworthy.

Govern source and workflow changes. Protect branches, require independent review for release-related code, and apply additional scrutiny to package manifests, lifecycle scripts, CI workflows, editor tasks, and AI-agent configuration. A valid signature should not override an unexpected or unreviewed change.

Correlate releases with source events. Before permitting publication or promotion, verify that an artifact maps to an approved commit, pull request, tag, workflow version, and expected build identity. Unexpected patch releases or artifacts without corresponding source activity should be investigated.

Restrict install-time execution. Disable npm lifecycle scripts in CI where they are unnecessary. Where scripts are required, isolate their execution, monitor network and process activity, and explicitly allow only known behavior.

Use ephemeral, least-privilege identities. Prefer short-lived credentials with narrowly scoped permissions. A build that only needs to read dependencies should not have standing access to publish packages, modify repositories, enumerate cloud secrets, or reach production infrastructure.

Isolate runners. Use disposable build environments, minimize credentials present in memory, restrict outbound connectivity, and rebuild runners after suspected exposure. Long-lived, broadly privileged runners increase both the value of stolen credentials and the worm’s opportunity to persist.

Gate artifact publication and promotion. Evaluate more than signature status. Policies should consider source review, dependency risk, suspicious new scripts, unusual package behavior, scanner findings, and the relationship between the source repository and published artifact.

For this incident specifically, organizations should first hunt for the reported token-monitoring persistence, editor hooks, package IOCs, and unexpected releases. Credential revocation and rotation should then occur from a known-clean environment, followed by rebuilding affected systems and downstream artifacts.

How Harness could help

Harness positions software supply chain security as a combination of dependency governance, security testing, policy enforcement, artifact controls, and delivery evidence not merely the presence of an attestation.

Harness Supply Chain Security supports assessing software supply chain posture, governing open source dependencies using software bills of materials, and managing artifact promotion with SLSA attestations. Harness messaging also emphasizes workflows for rapidly responding to vulnerable or compromised components.

The broader Harness platform can enforce organizational policies through Open Policy Agent, apply security gates within delivery pipelines, use fine-grained access controls, and maintain audit trails. Harness Artifact Registry is designed to centralize artifacts and dependencies while enforcing quality and security standards.

Applied to an incident like ChainDrop, those capabilities could help teams:

• govern which open source dependencies and package versions are permitted
• enforce a minimum package-age policy to delay adoption of newly published dependency versions
• require security and policy checks before publishing or promoting artifacts
• correlate attestations with approved delivery processes
• limit problematic packages through automated policy enforcement
• identify where affected components are used
• preserve audit evidence for investigation and remediation

These controls would not make provenance infallible or guarantee prevention. They could, however, strengthen the surrounding guardrails, reduce exposure, improve visibility, and accelerate remediation when trust signals conflict.

The bigger trend

ChainDrop reflects three converging trends.

First, software supply chain attacks increasingly target identities rather than only source code. npm tokens, GitHub credentials, cloud identities, and CI/CD permissions let attackers move through the same trusted paths maintainers use.

Second, developer environments now include more executable surfaces. Package lifecycle hooks, IDE tasks, automation files, and AI coding-agent configuration can all become persistence or propagation mechanisms.

Third, security decisions increasingly require combined evidence. Provenance, code review, dependency intelligence, workflow history, policy results, and runtime behavior each answer different questions. None is sufficient by itself.

Harness take

ChainDrop shows that “signed” and “safe” are not synonyms. Modern software delivery needs to establish continuity of trust from the proposed source change through the workflow, artifact, promotion decision, and runtime—not simply verify the identity of the pipeline that produced the final package.

Closing

ChainDrop does not make provenance unimportant. It clarifies its proper role.

Attestations remain valuable evidence about how software was produced, but trustworthy delivery requires controls before and after the build: reviewed source, governed workflows, constrained identities, policy-gated artifacts, isolated execution, and evidence from runtime behavior.

Harness helps organizations connect these controls across the software delivery lifecycle so that a valid signature becomes one input to a risk decision—not the entire decision.

Key takeaways

• SafeDep confirmed 444 affected npm package names and 2,234 poisoned versions as of its August 4 analysis.
• The worm executed during package installation and targeted developer, CI/CD, cloud, registry, Vault, and Kubernetes credentials.
• Legitimate OIDC publishing workflows produced artifacts with valid SLSA provenance after malicious inputs entered the pipeline.
• Teams should remove the reported token-revocation persistence before rotating credentials.
• Provenance should be combined with source governance, policy gates, dependency controls, least-privilege identities, and runtime evidence.

FAQ

What is the ChainDrop npm worm?

ChainDrop is the name used for a self-propagating npm supply chain campaign that inserts credential-stealing malware into packages and uses compromised publishing access to infect additional packages.

How can malware have valid SLSA provenance?

Provenance verifies information about the build process and identity that produced an artifact. When an authorized workflow builds already-compromised source, the resulting attestation can be valid even though the artifact is malicious.

What should teams do if they installed an affected package?

Treat the relevant developer machine or build runner as potentially compromised. Hunt for the published persistence mechanisms and indicators first, then revoke and rotate exposed credentials from a clean environment and rebuild affected systems and artifacts.