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 abused a maintainer account to plant credential-stealing code in widely used packages.

Why it matters: It matters because a single compromised maintainer can turn routine dependency installation into cross-environment NHI exposure across source control, CI/CD, cloud, and vault access.

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

Context

npm supply chain compromise becomes especially dangerous when it intersects with NHI secrets, because build-time automation can turn one poisoned package into credential theft at machine speed. In this case, the primary risk was not just malicious code in a dependency, but the automatic execution path that reached source control, CI/CD, cloud keys, and vault tokens without a user interaction step.

That pattern is familiar in modern software delivery: package trust, maintainer trust, and pipeline trust are often treated as separate controls when they function as one attack surface. For IAM and PAM teams, the question is no longer whether developers install trusted packages, but whether those installs can be used to harvest, reuse, and propagate NHI credentials across environments.

Key questions

Q: What breaks when malicious npm packages execute during CI/CD installs?

A: The main failure is that package installation becomes code execution inside a trusted build context. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

Q: Why do CI/CD tokens and maintainer credentials matter so much in supply chain security?

A: They are the identities that can publish packages, access build systems, and sign artifacts. If those credentials are long-lived or broadly scoped, attackers can turn one compromise into downstream package poisoning or secret theft. Treat them as privileged access paths with rotation, least privilege, and immediate revocation on suspicion.

Q: How do security teams know whether developer endpoints are leaking NHI secrets?

A: Look for unexpected token use, unusual outbound connections, unexplained browser profile access, and persistence mechanisms on workstations and build runners. If a compromised package executed on the machine, assume cloud keys, CI secrets, and other non-human credentials may already be exposed and rotate them before restoring trust.

Q: Who is accountable when a stolen maintainer account pushes malicious packages?

A: Accountability sits with both the project maintainers and the organisation operating the publishing identity. Teams should define who owns package release rights, who can revoke them, and how quickly compromised publisher access can be removed. That governance belongs in access review and offboarding processes.

Technical breakdown

How the maintainer account takeover became a package compromise

The entry point was compromise of the maintainer’s GitHub account, which gave attackers the ability to push malicious changes directly to the main branch. That matters because many open-source projects treat maintainer access as an implicit trust boundary for source integrity. Once malicious code reached the repository, automated build and publish workflows can transform a source change into a signed package release. In supply chain terms, the attack bypassed user phishing and moved straight to trusted publishing paths.

Practical implication: protect maintainer identities with strong phishing-resistant authentication and tightly scoped publishing permissions.

Why the hidden preinstall script is so effective

The malicious package used a preinstall script, which executes automatically during npm install before a project even runs. The script dropped a temporary Bun runtime and then executed obfuscated JavaScript to reduce visibility and delay detection. This is a classic execution-abuse pattern in dependency compromise: the malicious payload lives in a lifecycle hook that developers and CI pipelines rarely inspect closely. Because installation is routine, the attack scales wherever package managers run, including ephemeral build agents and developer laptops.

Practical implication: treat dependency install hooks as executable code and block or inspect them in CI/CD.

How stolen NHI secrets fuel self-propagation

The payload harvested npm tokens, GitHub credentials, AWS keys, Kubernetes secrets, vault tokens, SSH keys, and API keys from the local environment and runner memory. That makes the theft more than data exfiltration. It creates a propagation mechanism, because stolen npm credentials can be used to publish backdoored updates to additional packages the victim maintains. In other words, the compromised identity becomes both loot and launchpad, which is why NHI governance is central to supply chain resilience.

Practical implication: assume every install host may expose reusable NHI secrets and scope access so stolen tokens cannot publish or pivot.

Threat narrative

Attacker objective: The objective was to steal reusable NHI credentials and use them to spread malicious packages across the open-source ecosystem.

1. Entry occurred when attackers compromised a maintainer’s GitHub account and pushed malicious code into trusted package source.
2. Credential harvesting began when the hidden preinstall script executed automatically and collected npm, GitHub, cloud, vault, and runner-memory secrets.
3. Escalation and propagation followed when stolen npm credentials were reused to publish backdoored updates to additional packages the victim owned.
4. Impact was ecosystem spread, with routine npm installs becoming a mechanism for broader secret theft and downstream compromise.

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

Supply chain worms now weaponise NHI reuse, not just code distribution. ChainDrop shows that the real prize is not a single poisoned package, but the credential estate exposed by the install path. Once npm, GitHub, AWS, Kubernetes, and vault tokens are reachable from the same runner, compromise becomes a cross-domain identity event. The practitioner conclusion is clear: NHI governance must extend into software delivery trust chains, not stop at user identity.

Standing publishing trust is the control gap this campaign exploits. The attack works because maintainer accounts, CI publishing jobs, and package registry permissions are often assumed to be stable and legitimate. That assumption fails when a compromised maintainer can both publish malicious code and reuse stolen tokens to keep spreading. The governance lesson is that lifecycle control for privileged publishing identities is as important as code review. Practitioners should treat package publish rights as high-risk privilege, not routine developer access.

Secret exposure in build environments is the named failure mode here. This is not a generic malware story. It is a demonstration of secret reachability across runner memory, local config files, and environment variables, which turns one install event into multi-system credential theft. NHI Mgmt Group’s view is that ephemeral build trust without ephemeral credentials creates an exposure window that attackers can exploit at machine speed. The practitioner conclusion is to reduce the number of credentials any install path can see.

Open-source publishing is becoming an identity security control point. The package ecosystem now behaves like a delegated access plane, where a maintainer identity can influence thousands of downstream environments. That makes maintainer authentication, token scope, and offboarding discipline part of supply chain defense. In framework terms, the pattern maps directly to OWASP-NHI concerns, NIST CSF access governance, and MITRE ATT&CK credential access plus lateral movement. Practitioners should integrate software supply chain reviews into identity governance.

Mini Shai Hulud is less an isolated worm and more a repeatable operating model. The recurrence across different packages and maintainers suggests an attacker playbook built around credential theft, package reinfection, and automated propagation. That means defenders should expect variant reuse rather than one-off indicators. The conclusion for security teams is to build controls that survive campaign rebranding, because the governance flaw is stable even when the malware name changes.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• Another finding shows that 62% of all secrets are duplicated and stored in multiple locations, which increases accidental exposure and complicates revocation.
• That is why Guide to the Secret Sprawl Challenge is a useful next step for teams addressing install-time secret exposure and secret reuse.

What this signals

Secret sprawl is now a supply chain resilience issue, not just an IAM hygiene problem. When install-time code can reach multiple secret stores, the security boundary shifts from application trust to credential reachability. Teams should map which build systems can see npm tokens, cloud keys, and vault tokens, then remove secret access from every runner that does not need it.

The practical signal for identity programmes is that offboarding, token rotation, and publishing rights can no longer be managed as separate admin tasks. A compromised maintainer account plus reusable secrets creates a propagation path that outlives the initial incident, so review should focus on who can publish, who can rotate, and who can revoke across the software delivery chain. That is where NHI governance becomes a measurable control.

Secret reachability window: this is the period during which an install host can access credentials that should never be visible to dependency code. The shorter that window, the less useful a poisoned package becomes. Teams should align lifecycle controls to this boundary and treat package install contexts as privileged execution zones.

For practitioners

• Audit package install exposure paths Identify where npm install runs in developer workstations, CI/CD runners, and ephemeral build environments, then inspect which secrets those hosts can access during install. Remove unnecessary access to GitHub, cloud, and vault credentials from any machine that only needs to build packages.
• Reduce maintainer publishing blast radius Require phishing-resistant authentication for package maintainers, separate publishing rights from day-to-day development access, and review who can trigger automated releases to the npm registry. Treat publishing tokens as privileged credentials with explicit lifecycle ownership.
• Block or inspect lifecycle scripts in CI Use policy controls to detect or prevent unexpected preinstall and postinstall execution, especially for packages that are updated outside normal release windows. If lifecycle scripts must run, execute them in isolated runners with no reusable cloud or vault secrets.
• Rotate every credential reachable from poisoned hosts If a compromised package was installed, revoke and reissue npm tokens, GitHub PATs and OIDC tokens, AWS keys, Kubernetes service account tokens, and vault access tokens that were reachable from that host or runner.
• Tighten offboarding and token reuse controls Audit former maintainer access, duplicated secrets, and reused NHI credentials across packages so one stolen token cannot publish multiple repositories or persist after offboarding.

Key takeaways

• ChainDrop shows that package compromise becomes much more dangerous when install-time code can reach NHI secrets across CI/CD and cloud tooling.
• The scale is amplified by high-download dependencies, automatic preinstall execution, and token reuse that lets one compromise spread into many packages.
• Teams that control maintainer privilege, secret reachability, and lifecycle script execution are far better positioned to limit the blast radius.

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.
• Lifecycle Script: A lifecycle script is code that runs automatically during package installation or build steps, such as preinstall or postinstall hooks. These scripts are useful for legitimate automation but create a high-risk execution path because they can run before developers fully inspect the package.
• Maintainer Account Takeover: A compromise in which an attacker gains control of a software maintainer’s publishing identity. In package ecosystems, that can be enough to replace legitimate releases with malicious ones, making the account itself a production-grade access path rather than a simple administrative login.
• Secret reachability: The degree to which a runtime can access credentials, tokens, certificates, or configuration files at execution time. Secret reachability is a practical risk measure because a code-execution flaw is far more damaging when the compromised process can immediately read and reuse sensitive identity material.

What's in the full analysis

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

• IOC and hash coverage for setup.mjs, Math_Symbol.js, and related variants
• The package and version list needed for lockfile and dependency audits
• Campaign-specific GitHub Actions and npm log patterns for release investigation
• Observed attacker infrastructure and propagation indicators tied to the Shai Hulud lineage

👉 Expel's full post covers indicators, affected packages, and investigation details for the ChainDrop campaign.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle fundamentals. It helps security practitioners build controls that reduce exposure across software delivery, cloud, and access management.