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.
NHIMG editorial — based on content published by StepSecurity: ChainDrop npm worm analysis and recovery guidance
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read StepSecurity's full ChainDrop analysis of the npm worm and credential theft →
ChainDrop and CI/CD credential theft: what should teams do now?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ChainDrop npm worm exposes how CI/CD NHIs enable supply chain spread