ChainDrop npm worm exposes how CI/CD NHIs enable supply chain spread

At a glance

What this is: ChainDrop is a self-propagating npm supply chain worm that spread through CI/CD NHI abuse, package republishing, and developer tooling persistence.

Why it matters: It matters because CI/CD tokens, maintainer accounts, and runner secrets can turn a single poisoned release into ecosystem-wide propagation if lifecycle controls are weak.

By the numbers:

• StepSecurity says ChainDrop poisoned 444 packages and 2,212 versions in under four hours.
• The campaign started with [email protected], which had over 150M weekly downloads.
• StepSecurity reports that [email protected] reached 149.9M weekly downloads.
• StepSecurity reports that [email protected] reached 147.6M weekly downloads.

Context

ChainDrop is a supply chain worm that used compromised maintainer and CI/CD non-human identities to move from one poisoned release to the next. The important governance issue is not only malicious package code, but the trust model around release workflows, runner secrets, and developer tooling that can be reused once an attacker gets publish access.

In practical terms, this kind of campaign exposes the boundary between software supply chain security and identity governance. When maintainer accounts, OIDC-backed publishing, CI secrets, and agent-assisted developer environments all participate in the same release path, a single identity compromise can become a propagation mechanism rather than a contained incident.

Key questions

Q: What breaks when a CI/CD publishing identity is compromised in a supply chain worm?

A: A compromised publishing identity turns release automation into a propagation engine. The attacker can publish malicious packages, reuse runner secrets, and keep spreading through the same workflow that teams trust for normal releases. The real failure is that publication authority and distribution power sit behind one identity without enough separation or secondary checks.

Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?

A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.

Q: What are the signs that a package install has been turned into an execution path?

A: Look for unexpected lifecycle hook activity, Git-based dependencies, hidden child processes, new persistence files in developer tooling paths, and installs that touch network or secret-access APIs during routine dependency resolution. Those are indicators that package metadata is being used to trigger code, not just deliver code.

Q: Should teams trust signed or attested packages after maintainer compromise?

A: No. Signatures and provenance show that an artifact was produced by a workflow, but they do not prove the workflow owner was uncompromised. If the maintainer account or release path is hijacked, the resulting package can still be malicious and fully attested. Identity assurance has to accompany artifact assurance.

Technical breakdown

How the preinstall dropper turns package install into execution

The worm uses an npm preinstall hook, which runs automatically during dependency installation before most application logic starts. That makes the package install path itself an execution vector. In this case, the first stage downloads the Bun runtime and then launches a second-stage payload, so the package is not just present in the dependency tree. It actively runs code during build or install. For defenders, this matters because traditional package inspection often treats install-time behavior as routine, even when a package is using that behavior to bootstrap an attacker-controlled runtime.

Practical implication: Treat preinstall scripts as code execution points and inspect them with the same suspicion as build pipelines.

Why CI/CD secrets become a propagation channel

The payload is designed to steal GitHub tokens, npm tokens, cloud credentials, and runner secrets from machines and CI jobs that install the package. Once those secrets are harvested, the worm can republish itself from the victim's own identity, which creates a self-amplifying loop. This is the core NHI problem: a publish token or runner secret is not just an access credential, it is a distribution credential. If the token can publish packages or trigger release workflows, compromise of that identity can spread code at machine speed across unrelated projects.

Practical implication: Limit publish and runner credentials to the narrowest possible scope and rotate them as soon as install-time abuse is suspected.

How trusted publishing and provenance still leave room for abuse

The article shows why trusted publishing and SLSA provenance are necessary but insufficient. Provenance can confirm which commit produced an artifact, but it cannot confirm whether the maintainer identity behind that commit was legitimate at the time of release. In a compromised maintainer scenario, the attacker can use the project's own release workflow to produce artifacts that look clean to automation. That means provenance controls are strongest against unauthorized build tampering, but much weaker when the release authority itself is compromised.

Practical implication: Pair provenance checks with maintainer identity hardening, release approval controls, and separate verification of who can trigger publication.

Threat narrative

Attacker objective: The attacker objective was to turn one compromised maintainer or CI/CD identity into a self-propagating package distribution channel with credential theft, republishing, and persistence.

1. Entry began when attackers compromised maintainer identities and release workflows in npm projects, then used those accounts to push poisoned commits and tags.
2. Credential harvest occurred through install-time code that collected npm tokens, GitHub tokens, cloud credentials, runner secrets, and developer environment data.
3. Escalation happened when the stolen credentials were reused to republish the worm into additional packages and versions from victims' own identities.
4. Impact was ecosystem spread across hundreds of packages, with persistence into AI developer tooling and ongoing republishing as new credentials were obtained.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

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

CI/CD publish credentials are now supply chain transport, not just access control: this incident shows that runner secrets, maintainer tokens, and release identities can become the mechanism that moves malicious code from one project to many. Once publication is tied to a compromised identity, the attacker inherits the project's distribution power. Practitioners should treat publishing authority as a high-risk NHI with blast-radius controls, not as a routine build artifact.

Trusted publishing reduces one class of tampering but does not solve maintainer compromise: provenance can tell you what commit was built, but not whether the person or workflow authorizing that commit was legitimate. That is a governance gap, not a cryptography gap. Security teams should stop assuming that signed or attested packages are automatically trustworthy when the signing identity itself can be hijacked.

ChainDrop is a clear example of credential-to-propagation conversion: the named concept here is the conversion of a single stolen CI/CD secret into repeated package publication. That pattern is more dangerous than one-off theft because it creates a live replication loop that keeps feeding on new tokens and release rights. The control failure is lifecycle containment of publish identities, not package scanning alone.

Developer tooling is becoming part of the attack surface for supply chain worms: persistence into Claude Code, VS Code, and GitHub Copilot workflows means the payload is trying to survive beyond the build system. That widens the governance problem from CI security to workstation and agent configuration hygiene. Teams should assume developer IDE and agent settings are now part of the release integrity boundary.

For identity programmes, the lesson is that NHI governance must extend into software delivery: package publication, runner access, and workflow triggers are identity events with direct security consequences. The relevant question is no longer only who can log in, but which non-human identities can publish, republish, and persist without separate checks. Practitioners should fold release identities into the same governance model used for other high-value NHIs.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Credential-to-propagation conversion: this incident shows that a stolen CI/CD secret can do more than expose data. It can turn release automation into an attack distribution system, which is why publish identities need blast-radius controls and separate approval paths.

The practical signal for practitioners is that package provenance, signed releases, and trusted publishing should be treated as layered controls, not proof of trust by themselves. When maintainer identity is the point of compromise, the governance model has to focus on who can trigger release and what that identity can reuse.

Repository and runner inventories should now include developer tool configuration and AI agent settings, because the payload persisted into those locations as part of its spread. That widens the operational boundary from software supply chain to endpoint and agent configuration hygiene.

For practitioners

• Audit publish identities as privileged NHIs Inventory every maintainer token, OIDC publishing path, runner secret, and release workflow that can publish artifacts. Map who or what can trigger publication, then reduce each path to the smallest possible scope and approval surface.
• Isolate CI/CD runners from reusable secrets Remove long-lived credentials from runners where possible and prefer short-lived, task-scoped access for package release operations. Treat any runner that handled a compromised package as contaminated until secrets are rotated and caches are checked.
• Search lockfiles and build systems for affected versions Check package-lock.json, yarn.lock, pnpm-lock.yaml, build caches, and developer machines for the compromised package names and versions. Include transitive dependencies, because the worm spread through packages teams did not intentionally select.
• Review install-time scripts before dependency ingestion Block or flag packages that execute preinstall or equivalent install-time scripts unless the behavior is explicitly approved. Install-time execution is the point where dependency ingestion becomes code execution.
• Revalidate release workflows after maintainer compromise Separate commit authorization, release approval, and artifact publication where possible so a compromised maintainer account cannot directly turn a clean workflow into a malware distributor.

Key takeaways

• ChainDrop shows that a compromised CI/CD publishing identity can become the transport layer for a supply chain worm, not just a point-in-time access issue.
• The campaign spread through 444 packages and 2,212 versions in under four hours, which is the kind of velocity that invalidates manual lockfile checks.
• The control gap is lifecycle governance for release identities and runner secrets, backed by install-time script scrutiny and fast revocation.

Key terms

• CI/CD Non-Human Identity: CI/CD non-human identity is the account, token, key, or certificate used by automation in build and release pipelines. These identities often have broad access and can influence production outcomes, which makes ownership, rotation, and least privilege critical controls rather than administrative details.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• 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 Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps security and identity practitioners build governance that matches the way modern release pipelines actually work.