ChainDrop shows how npm supply chain worms now steal NHI secrets

At a glance

What this is: ChainDrop is a self-propagating npm supply chain worm that used a compromised maintainer account and install-time code to harvest multiple credential types from development and CI environments.

Why it matters: It matters because the compromise path is not limited to package integrity. It crosses into NHI governance, cloud access, and CI/CD secrets, which means dependency controls and credential controls now need to be treated as one attack surface.

Context

ChainDrop sits at the intersection of software supply chain risk and non-human identity governance. A package install is supposed to be a build-time dependency event, but here it became a credential capture point because the malicious code executed automatically inside developer and CI contexts. That changes the control problem from package trust alone to the trust placed in tokens, secrets, and build-time identities.

The article describes a pattern that many organisations still under-estimate: a compromised maintainer account can turn widely used open-source packages into a credential collection layer. That is atypical only in the scale of propagation, not in the underlying weakness, because install scripts, publishing tokens, and cloud secrets often remain more exposed than teams assume.

Key questions

Q: What breaks when security teams rely on postinstall hooks and broad CI secrets to build npm packages?

A: Postinstall hooks turn package installation into code execution, so any compromised dependency can run immediately on developer laptops and build runners. Broad CI secrets then become easy to harvest and reuse for republishing or persistence. This combination breaks the assumption that installs are passive, and it gives attackers a direct path from dependency compromise to registry abuse.

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 signs suggest npm or GitHub publishing identities are being abused?

A: Look for unexpected package versions, releases outside normal maintainer patterns, install scripts in packages that previously did not use them, and CI jobs that access secrets without a matching operational change. Abnormal publication timing and unplanned dependency changes are often the earliest clues.

Q: Should teams treat package signing as enough protection against malicious releases?

A: No. Signing confirms that a trusted identity produced the artifact, not that the identity itself was uncompromised. If a maintainer account or publishing token is taken over, signed malware can still enter the registry through normal release pipelines, so identity assurance and artifact trust must be governed together.

Technical breakdown

How a maintainer account compromise becomes a package trust failure

The first control break is not code execution in the abstract, but trust in the publisher identity behind an npm package. If an attacker controls the maintainer’s GitHub account, they can push changes to the main branch, trigger automated build pipelines, and publish signed package updates that look legitimate to downstream consumers. In this model, package integrity checks alone do not solve the problem because the malicious artifact was created through normal delivery paths. The real weakness is the assumption that a valid publishing identity implies safe content. In NHI terms, the maintainer’s publishing credentials became the attack path, not just the package itself.

Practical implication: treat maintainer accounts, publishing tokens, and CI-triggered release paths as privileged identities that require strong lifecycle and anomaly controls.

Why preinstall scripts are such a high-risk execution path

npm preinstall scripts run automatically during installation, which makes them an ideal delivery mechanism for malware that wants to execute before a developer notices anything unusual. In this case, setup.mjs launched a Bun runtime and then executed obfuscated JavaScript, which reduces the chance that standard review processes or repository scanning will catch the payload quickly. The architecture matters because install-time execution happens in trusted build and developer contexts where environment variables, local files, and cached credentials are often available. That turns a dependency update into a runtime compromise opportunity.

Practical implication: restrict or block install scripts in high-trust environments and inspect packages that rely on post-install execution.

How stolen secrets turn a single compromise into worm-like propagation

The payload’s value comes from what it can collect after execution: npm tokens, GitHub credentials, cloud keys, Kubernetes secrets, and Vault access tokens. Those are not just data to exfiltrate. They are delegation mechanisms that let the attacker publish additional poisoned packages, access infrastructure, and continue spreading without reusing the original maintainer account. That is why this campaign behaves like a worm rather than a one-off theft. The attacker converts one publishing compromise into a credential relay across source control, package registries, and cloud control planes.

Practical implication: map where build-time credentials can publish, deploy, or read secrets, then reduce those permissions to the minimum viable scope.

Threat narrative

Attacker objective: The attacker aimed to steal reusable NHI secrets and turn one maintainer compromise into self-propagating access across the open-source ecosystem.

1. Entry occurred when attackers compromised the GitHub account of a maintainer and pushed malicious code into widely used npm packages.
2. Credential harvesting began when the hidden preinstall script executed during npm install and collected npm, GitHub, AWS, Kubernetes, Vault, SSH, and API secrets from the local environment.
3. Escalation happened when stolen npm tokens were reused to publish backdoored updates to additional packages, allowing the worm to propagate through trusted publishing channels.
4. Impact was the spread of infected packages and the exposure of development, CI/CD, and cloud credentials across the affected environments.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.

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

ChainDrop is a governance failure in publishing identity, not just a malware event. The attack worked because the maintainers’ publishing path was trusted enough to turn account takeover into signed package distribution. That means package provenance controls and NHI credential governance are now inseparable in software delivery. Practitioners should treat maintainer access as a privileged supply chain identity.

Install-time execution is the point where dependency trust becomes credential exposure. The article shows that a routine npm install can reach local files, environment variables, and CI runner memory before defenders have much chance to intervene. That is the operational blind spot. The right frame is not “malicious package” alone, but “trusted install path as a secret collection surface.”

Self-propagating package malware is increasingly an identity problem. Once the worm harvested npm tokens, it no longer needed the original maintainer account to keep moving. That shifts the control focus from single-account compromise to delegated publishing authority, token scope, and offboarding speed. Teams should assume that one compromised token can become many compromised releases.

ChainDrop sharpens a named concept: credential-amplified supply chain propagation. A package compromise becomes materially more dangerous when the payload can steal the very credentials needed to publish the next malicious update. This is a feedback loop between software trust and identity trust. Practitioners need controls that break that loop before release credentials can be reused.

The broader lesson is that NHI secrets inside build systems now define blast radius. AWS keys, Kubernetes tokens, Vault access, and GitHub tokens are all high-value outcomes for this class of worm because they extend the incident beyond source control. Governance should therefore assess where CI/CD identities can reach, not just whether the package is signed. Practitioners should narrow credential scope and watch publishing activity as a security signal.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• Read next: Secrets Management Buyer's Guide

What this signals

Credential-amplified supply chain propagation: this is the pattern practitioners should now expect when install-time malware can steal the same tokens used to publish, deploy, and access secrets. The control problem moves from package integrity alone to the reach of every build-time identity, which is why publishing permissions and secret scope must be reviewed together.

The practical lesson is that CI/CD environments are now credential reservoirs, not just build systems. When a package install can reach cloud keys, Vault tokens, and registry credentials in one pass, blast radius is defined by what those identities can do, not by where the malware first landed.

For practitioners

• Audit package install paths for script execution Review npm, pnpm, and yarn workflows to identify packages that execute preinstall or postinstall logic during routine dependency updates. Block or sandbox install-time scripts in environments that have access to cloud tokens, Vault, or registry credentials.
• Rotate all secrets exposed to build and runner environments Revoke and reissue npm auth tokens, GitHub PATs and OIDC tokens, AWS access keys, Kubernetes service account tokens, and Vault credentials on any host or CI runner where an affected package was installed.
• Constrain publishing and release permissions Separate package publishing from routine developer access, and reduce the number of identities that can publish to npm or trigger release workflows from GitHub Actions.
• Monitor for abnormal package publication activity Check registry logs, release pipelines, and GitHub Actions history for unexpected publishes, new package versions, or maintainer activity that does not match normal release cadence.

Key takeaways

• ChainDrop shows that a package install can become a secret-harvesting event when maintainer identity and build-time credentials are both in scope.
• The worm’s danger comes from reuse of stolen publishing tokens, which turns one compromised release path into repeated package poisoning.
• Breaking this pattern requires tighter control over install scripts, publishing authority, and the credentials exposed inside CI/CD and developer environments.

Key terms

• Self-Propagating Supply Chain Worm: A self-propagating supply chain worm is malicious code that spreads by abusing trusted software distribution paths. It compromises a package, update, dependency, or build process, then automatically infects downstream systems and connected environments. In security terms, it weaponizes trust relationships, signing workflows, and automation to expand without repeated attacker action.
• 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.
• Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.
• Credential Amplification: Credential amplification is the process by which one exposed secret leads to access to more secrets, higher privileges, or additional systems. In worm-style attacks, stolen tokens are not the end goal but the mechanism that expands reach across registries, CI/CD, cloud platforms, and secret stores.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the build and release environments their programmes depend on.