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 used compromised maintainer and CI/CD non-human identities to steal credentials, republish packages, and persist in developer tooling.

Why it matters: It matters because IAM and PAM teams have to treat build pipelines, package publishers, and AI coding tools as governed identity surfaces, not just software delivery mechanics.

By the numbers:

• ChainDrop poisoned 444 packages and 2,212 versions in under four hours across more than a dozen victim organisations.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read StepSecurity's full ChainDrop analysis of the npm worm and credential theft

Context

ChainDrop is a supply chain worm that turns compromised package maintainer identities and CI/CD secrets into a replication engine. The security gap is not just malicious code in npm, but the combination of trusted publishing, automated release workflows, and long-lived non-human credentials that can be reused before defenders revoke them.

This is a direct identity governance problem as well as a software supply chain problem. Once a maintainer account, token, or runner secret is stolen, the attacker can publish from legitimate workflows, persist in developer environments, and expand through downstream package consumers before standard release provenance checks expose anything unusual.

Key questions

Q: What breaks when an npm maintainer identity is compromised in a CI/CD pipeline?

A: The release process itself becomes part of the intrusion path. A compromised maintainer identity can publish malicious versions, trigger trusted workflows, and reuse automation secrets to keep spreading. The failure is not only malware execution, but uncontrolled authority over package publication and the CI/CD identities that support it.

Q: Why do CI/CD service accounts and publishing tokens need the same governance as human access?

A: Because attackers increasingly use them as the primary route to code publication and secret harvest. These identities can sign releases, access build systems, and pull environment variables at machine speed. If they are not lifecycle-managed, monitored, and revoked quickly, they create a standing privilege path that is hard to contain.

Q: What do security teams get wrong about signed software?

A: Many teams treat signing as proof of safety when it is really proof of origin and, depending on the certificate type, proof of stronger identity assurance. A signed file can still be malicious if the publisher identity is compromised or the release process is weak.

Q: How should organisations respond when malicious code has already run in a build or developer environment?

A: Contain the endpoint, revoke the exposed secrets, and check for follow-on compromise in repositories and cloud accounts. Uninstalling the package is not sufficient if persistence, exfiltration, or secondary payloads were already established. Response has to cover the host, the identities it touched, and any downstream systems those identities can reach.

Technical breakdown

How the preinstall loader turns npm installs into execution

The first stage uses npm lifecycle execution, specifically a preinstall hook, to run as soon as the package is installed. In this case the loader retrieves Bun, then hands off to an obfuscated second stage. That matters because the malicious code does not need the victim to open a file or click a link. It runs inside the normal developer and CI/CD install flow, where package managers are trusted to execute setup logic automatically. Once execution starts in that context, the attacker inherits whatever secrets, environment variables, and repository access the build job can see.

Practical implication: restrict lifecycle-script execution in build and developer environments where possible, especially for newly released or unreviewed packages.

Why stolen CI/CD and maintainer credentials enable self-propagation

The worm spreads by using compromised maintainer identities to publish poisoned versions and by harvesting tokens from CI runners and developer machines for the next wave. That makes the credential, not the package alone, the replication unit. Because many releases used valid trusted publishing and provenance attestations, automated verification could confirm what commit was built but not whether the commit was authorized. In other words, provenance establishes build lineage, while identity compromise controls what gets built and shipped.

Practical implication: bind release permissions to strongly governed maintainer identities and short-lived publishing credentials, not to account possession alone.

How persistence moved into AI developer tooling and dead-drop C2

The payload also planted hooks in .claude and .vscode paths so it could re-trigger in AI-assisted developer workflows. It used an Ethereum-backed command channel as dead-drop infrastructure, which reduces dependence on a static domain that defenders can sinkhole quickly. The exfiltration design was layered to resist inspection, wrapping stolen data in compression, encryption, and key wrapping before transmission. That combination means the attacker is not only stealing secrets, but building durable remote control and re-entry points across the development estate.

Practical implication: include AI coding tool configuration directories, GitHub Actions runners, and package caches in incident response and persistence searches.

Threat narrative

Attacker objective: The attacker objective is to convert one compromised maintainer or runner identity into repeated package publication, credential harvesting, and durable control over downstream development environments.

1. Entry began when poisoned npm packages executed a preinstall loader during normal install activity on developer machines and CI runners.
2. Credential access followed as the payload harvested npm tokens, GitHub tokens, cloud credentials, and runner secrets from local environments and workflow memory.
3. Escalation and lateral movement occurred when stolen maintainer identities were used to republish malicious packages across unrelated organisations.
4. Impact was achieved through rapid supply chain spread, persistence in developer tooling, and encrypted exfiltration over attacker-controlled command infrastructure.

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

ChainDrop shows that CI/CD secrets are now first-class non-human identities, not disposable build artifacts. The worm did not need a novel exploit chain once it reached package publishing credentials and runner context. It simply reused the access that modern delivery pipelines already grant to automation, which is why secrets governance and package governance now overlap. Practitioners should treat build-time tokens, release OIDC trust, and maintainer accounts as a single governed identity surface.

Trusted publishing did not fail because provenance is useless. It failed because provenance is not authorisation. The incident demonstrates a governance gap that many release programmes still miss: cryptographic attestation can show where a package came from, but it cannot prove that the person controlling the source commit was supposed to publish it. That distinction matters for any release process that assumes “signed” is the same as “safe”. Practitioners should add identity and approval controls around release authority, not only artifact verification.

Secrets sprawl inside developer tools is now part of the attack surface for AI-assisted engineering. ChainDrop persisted in .claude and .vscode paths, which means the malware understood that modern developer workflows extend beyond source control and package managers. AI coding assistants, editor tasks, and local automation files can become hidden re-entry points if they are not inventoried and monitored. Practitioners should extend control coverage to AI developer tooling alongside npm, GitHub, and CI runners.

Standing privilege in publishing pipelines is the named failure mode this worm exploited. The attack succeeded because access to publish, republish, and trigger releases remained available long enough for stolen credentials to be reused across multiple organisations. That is a classic standing-privilege problem in a modern supply chain setting, and it is exactly where JIT access, tighter release ownership, and rapid token revocation have the most value. Practitioners should reduce the usable lifetime of every publishing identity.

ChainDrop validates the need for identity-centric supply chain governance across OWASP NHI and core security controls. The worm is not just malware in npm, it is a lesson in how malicious automation weaponises non-human identities at scale. Controls such as secret rotation, release segregation, and continuous monitoring need to be aligned to the identities that actually publish code, not just the repositories that store it. Practitioners should govern the publisher, the runner, and the package as one access chain.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• A separate finding from our research shows that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which means detection without revocation leaves attackers a long-lived path.
• Forward-looking analysis is available in Guide to the Secret Sprawl Challenge, which shows why secret inventory and rotation must be tied to identity lifecycle controls.

What this signals

Secret exposure is now a time-to-compromise problem, not only a detection problem. When malicious package installs can harvest and reuse tokens before teams finish triage, the operational priority shifts to exposure reduction and rapid revocation. That is why identity lifecycle controls, token TTLs, and automated offboarding are becoming central to software supply chain resilience.

Standing publishing access is the governance debt that continues to compound across development estates. The more release authority is embedded in long-lived accounts, local tooling, and runner contexts, the more opportunities an attacker has to reuse it. Teams should expect AI coding tools, package caches, and CI runners to become routine search targets during response, not just source repos.

The practical signal for programme owners is simple: if you cannot inventory every entity that can publish code or read workflow secrets, you do not yet have a governed identity boundary. That is the gap to close before the next self-propagating package campaign reaches your estate.

For practitioners

• Inventory all package publishers and runners Build a live list of maintainer accounts, OIDC publishing identities, GitHub Actions runners, and package automation tokens that can publish to npm or related registries. Cross-check those identities against every package version released during the incident window.
• Revoke and reissue every exposed token Rotate npm tokens, GitHub tokens, cloud keys, SSH credentials, and workflow secrets that were present on any machine or runner that installed the affected versions. Treat token reuse as likely until proven otherwise.
• Search developer tooling for persistence paths Inspect .claude, .vscode, build caches, and repository hooks for files that can relaunch the payload or rehydrate exfiltration paths. Include endpoints, CI runners, and ephemeral build workers in the same sweep.
• Block install-time execution where possible Reduce the blast radius of malicious lifecycle scripts by tightening package review, disabling unnecessary preinstall execution, and isolating installs for newly published or high-risk dependencies.

Key takeaways

• ChainDrop turned ordinary npm install flows into a supply chain worm by abusing maintainer and CI/CD identities.
• The incident confirms that trusted publishing and provenance do not stop a compromised authorisation path from shipping malware at scale.
• Practitioners need tighter control over publishing identities, faster token revocation, and broader inspection of developer tooling persistence points.

Key terms

• Self-propagating worm: A self-propagating worm is malware that automatically spreads from one compromised system to another without waiting for a human operator to copy it. In software supply chains, propagation often happens through trusted accounts, package registries, or update channels that the worm can reuse.
• 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.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full analysis

StepSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

• Full package and version lists for the 444 poisoned releases and 2,212 compromised versions
• Payload and IOC detail for the Bun loader, obfuscated second stage, and dead-drop C2
• Triage guidance for CI runners, developer machines, and affected lockfiles
• Recovery steps for republishing, token revocation, and environment reimaging

👉 StepSecurity's full post covers the attack timeline, payload mechanics, and recovery guidance for affected maintainers and teams.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and the controls that help teams reduce standing privilege in automation. It is designed for practitioners who need to connect identity governance to real-world build, release, and runtime risk.