Topic starter
18/08/2026 2:16 pm
TL;DR: ChainDrop is a self-propagating npm worm that poisoned 444 packages and 2,212 versions in under four hours, using a Bun-loaded preinstall dropper to steal CI/CD credentials, republish malware, and persist in AI developer tooling, according to StepSecurity. The incident shows that trusted publishing, valid provenance, and signed releases do not stop a compromised maintainer identity from shipping malicious code.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “ChainDrop npm Worm: Bun-loaded CI/CD credential harvester with Ethereum dead-drop C2”.
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.
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.
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.
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.
Practitioner guidance
- Audit publish identities as privileged NHIs Inventory every maintainer token, OIDC publishing path, runner secret, and release workflow that can publish artifacts.
- 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.
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:09 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ChainDrop npm worm exposes how CI/CD NHIs enable supply chain spread