Notifications
Clear all
Topic starter
18/08/2026 2:19 pm
TL;DR: A compromised GitHub maintainer account let ChainDrop push malicious code into high-download Node.js packages, where an automatic preinstall script harvested npm, GitHub, AWS, Kubernetes, and Vault credentials and reused stolen tokens to spread further, according to Expel. The incident shows that supply chain compromise and NHI credential theft now reinforce each other across source control, CI/CD, and cloud runtime trust boundaries.
NHIMG editorial — based on content published by Expel covering the ChainDrop npm supply chain attack: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Expel's analysis of the ChainDrop npm supply chain worm →
ChainDrop’s npm worm: what does it mean for NHI governance?
Explore further
18/08/2026 3:11 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ChainDrop shows how npm supply chain worms now steal NHI secrets
