ChainDrop shows how npm supply chain worms turn tokens into blast radius

At a glance

What this is: ChainDrop is a self-propagating npm supply chain worm that uses compromised maintainer identity, install-time execution, and token abuse to spread across packages and build systems.

Why it matters: It matters to IAM and security teams because it shows how one exposed publishing credential can turn software supply chain access into large-scale operational compromise.

By the numbers:

• This campaign has already touched more than 400 npm packages across multiple unrelated publishers.
• keyv alone sees more than 600 million monthly downloads.

👉 Read Veracode's analysis of the ChainDrop npm supply chain worm

Context

npm supply chain compromise is not just a developer tooling problem. It is an identity and governance problem because a stolen maintainer account or publishing token can be used to publish trusted-looking packages, trigger install-time code execution, and spread malicious releases across build pipelines and downstream consumers.

The article centers on a classic trust failure: organisations assume package provenance, signatures, or repository ownership are enough to prove safety. In practice, software distribution identity, CI/CD secrets, and developer workstation credentials sit in the same attack path, which is why non-human identity governance is relevant here even though the subject is application supply chain security.

For identity teams, the starting position is typical of modern software delivery. Publishing credentials are powerful, poorly scoped, and often under-monitored, which makes them a reusable entry point for attackers rather than a narrow operational tool.

Key questions

Q: What breaks when npm package installation is allowed to execute lifecycle scripts by default?

A: A malicious dependency can run code before installation completes, which turns normal package resolution into a payload delivery mechanism. That breaks the assumption that package trust equals install safety. Teams need to treat lifecycle execution as a privilege boundary and restrict scripts that are not essential to the build.

Q: Why do stolen publishing tokens create such a large supply chain risk?

A: A publishing token inherits the release authority of the maintainer identity behind it, so one compromise can create many malicious releases across every package the token can write to. The risk is not the token alone, but the scope and downstream trust attached to that identity. Narrow token scope and fast revocation are the main reducers of blast radius.

Q: What do security teams get wrong about signature checks for open source packages?

A: They often treat provenance signatures as proof that a package is safe to execute. In reality, a package can be signed, look legitimate, and still contain malicious lifecycle scripts or injected payloads. Signature validation should be one input to trust decisions, not the final gate.

Q: Who is accountable when a supply chain worm spreads through developer and CI environments?

A: Accountability sits across application security, platform engineering, and identity governance because the compromise crosses package trust, build execution, and credential management. The practical question is who owns publishing tokens, who controls build policy, and who can revoke exposed secrets quickly enough to contain spread.

Technical breakdown

How install-time execution turns a package into a delivery mechanism

ChainDrop relies on npm lifecycle behavior, especially the preinstall hook, which runs before installation completes. That means a malicious package does not need a separate exploit path once it lands in a dependency graph. The package executes as part of normal developer or CI activity, so the attack surface is the build process itself. This is why signature verification and repository trust are not enough if the package contents or scripts can still execute at install time. In supply-chain terms, the package is both artifact and runtime payload.

Practical implication: Block unexpected lifecycle scripts and treat any package installation as a potential execution event, not just a file transfer.

How stolen publishing tokens let one identity become many releases

The worm's key mechanism is token reuse. After compromising a maintainer identity, it enumerates every package that publishing token can write to, downloads the latest tarball, injects malicious code and a loader, increments the patch version, and republishes. This is non-human identity abuse in a supply-chain context: a secret tied to a legitimate publishing workflow becomes a propagation node. The technical risk is not only compromise of one account, but the inherited authority attached to that account's package scope and release permissions.

Practical implication: Scope publishing tokens tightly and review which package namespaces each token can release to.

Why attacker-controlled C2 and credential harvesting increase dwell time

The malware searches for credentials across developer workstations and CI/CD environments, including cloud keys, Kubernetes secrets, Vault access, SSH keys, and IDE or AI assistant configurations. It then exfiltrates data through encrypted channels and uses alternate paths such as attacker-created GitHub repositories if needed. Its command-and-control design is also resilient because the domains are fetched from an Ethereum smart contract rather than hardcoded. That means defenders face both credential theft and infrastructure agility in the same campaign.

Practical implication: Monitor for unusual credential discovery patterns, new repository creation, and install-time script anomalies across dev and CI estates.

Threat narrative

Attacker objective: The attacker aims to turn a single compromised publishing identity into a self-sustaining package worm that spreads malicious code, steals secrets, and expands reach across npm and CI environments.

1. Entry begins with compromise of a GitHub maintainer identity in the keyv and cacheable ecosystem, giving the attacker legitimate publishing access.
2. Credential access follows through install-time execution, where the preinstall hook harvests tokens, cloud secrets, SSH keys, Vault access, and related developer credentials.
3. Escalation happens when the stolen npm publishing token is reused to republish malicious patch releases across every package the identity can write to.
4. Impact is ecosystem-wide propagation, encrypted exfiltration, and persistence through developer tooling and fallback GitHub repositories.

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 publishing identity is now a production security control, not a developer convenience. A maintainer token can trigger release propagation across hundreds of packages, which means release authority is equivalent to downstream access authority. That collapses the old separation between source control and runtime risk. Practitioners should treat package publishing credentials as governed identities with lifecycle, scope, and monitoring requirements.

Install-time execution is the real control gap, not package trust alone. The worm succeeded because npm assumes lifecycle scripts are ordinary software behavior, even when they execute before installation completes. That creates a trust gap between provenance and execution. Controls that inspect package names or signatures without constraining lifecycle behavior leave the most dangerous part of the attack path untouched. Practitioners should focus on execution gating, not just artifact verification.

Credential sprawl in developer tooling creates a hidden lateral movement layer. This campaign did not stop at npm tokens. It sought cloud keys, Vault access, SSH material, Kubernetes secrets, and even AI assistant configurations, which shows how development environments have become identity-rich targets. The boundary between software supply chain compromise and broader NHI exposure is now thin. Practitioners should govern build identities, not just application secrets.

Blast radius is the right concept for supply-chain identity governance. One compromised maintainer account can amplify into billions of downstream installs when package scopes are broad and republishing is automated. That is a governance failure, not just a malware event. The named concept here is publishing-token blast radius, meaning the total downstream exposure created by one identity's release authority. Practitioners should measure and shrink that blast radius before attackers do.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes - and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Secret exposure is not a slow-moving problem. In The State of Secrets in AppSec, the average estimated time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities.
• For lifecycle and rotation context, read NHI Lifecycle Management Guide for governance patterns that reduce standing credential exposure.

What this signals

Publishing-token blast radius: the practical unit of risk in modern supply chain governance is no longer a repository or package, but the amount of downstream trust one identity can influence. That means build teams need visibility into who can publish, where those credentials are stored, and how quickly they can be revoked when compromise is suspected. The OWASP Non-Human Identity Top 10 is a useful lens for mapping that exposure class.

This campaign also shows why dependency policy and identity policy need to converge. If your CI/CD environment can execute package scripts, read cloud secrets, and reach developer tooling, then your software delivery pipeline already contains high-value non-human identities that deserve lifecycle control. The NIST Cybersecurity Framework 2.0 is relevant here because govern, protect, detect, and recover all need to include build identity.

For practitioners, the signal is clear: exposure windows are shrinking faster than most remediation cycles. According to The State of Secrets in AppSec, leaked secrets can remain unresolved for weeks, while compromise attempts can begin within minutes. That gap is where supply chain worms win, so the priority is reducing secret reachability before the next install event.

For practitioners

• Remove affected package versions from all build paths Inventory npm lockfiles across repositories, CI runners, and developer workstations, then quarantine any dependency versions linked to the campaign before the next build executes.
• Rotate publishing and build credentials immediately Revoke and replace npm tokens, GitHub credentials, cloud keys, Vault access, Kubernetes secrets, and any CI/CD secrets that may have been present when tainted packages were installed.
• Restrict package publishing authority Limit each maintainer token to the minimum package scope required, enforce strong MFA on maintainer identities, and remove unused publishing paths that expand token blast radius.
• Block risky lifecycle scripts by policy Detect and fail builds that invoke unexpected preinstall hooks or modified lifecycle scripts, especially in dependencies that should not require code execution during installation.
• Rebuild from clean, verified sources Use reproducible builds, pin known-good dependency versions, and maintain an up-to-date SBOM so exposure checks can be completed quickly across all environments.

Key takeaways

• ChainDrop turns npm publishing identity into a propagation path, showing that compromised maintainer access can rapidly become ecosystem-wide exposure.
• The campaign demonstrates that install-time execution and broad token scope are the two control gaps that make supply chain worms effective.
• Teams should focus on credential scope, lifecycle-script gating, and clean rebuild discipline to reduce the blast radius of the next package compromise.

Key terms

• 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.
• Token Blast Radius: Token blast radius is the amount of damage an attacker can do if a token is stolen, over-scoped, or reused too widely. The broader the token’s reach across APIs, the more services, data sets, and business functions a single compromise can expose.
• 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.
• Developer Tooling Trust: The assumption that approved development tools are safe to run inside a workstation or engineering environment. In practice, extensions, plugins, and add-ons can inherit broad permissions and become identity-adjacent access paths when their trust is not bound to device posture and session scope.

What's in the full article

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

• Step-by-step attack chain reconstruction across keyv, cacheable, and the wider npm propagation path
• Indicators of compromise including modified lifecycle scripts, new repositories, and obfuscated payload traits
• Detailed remediation sequence for CI/CD, developer endpoints, and publishing identities
• Veracode's package firewall and supply chain control workflow for blocking active malicious versions

👉 Veracode's full post covers the attack chain, exposure scope, and containment steps in more detail

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity controls to real-world operational risk.