Topic starter
11/05/2026 8:17 pm
TL;DR: A new Shai Hulud-style supply chain campaign is abusing npm install time to harvest developer and CI/CD secrets, with researchers reporting more than 26,000 affected repositories and 8.4 million exposed secret findings, according to Entro Security research. The pattern shows that supply chain compromise now lands directly on NHI governance, where token scope, rotation, and revocation determine blast radius far more than package trust alone.
Editorial analysis by NHI Mgmt Group, based on content published by Entro Security: “Shai Hulud 2.0: Zapier, GitHub and the Worm Turning npm Installs into Secret Exposure Pipelines”.
By the numbers:
- The top 5% of affected repositories were responsible for 57.0% of all exposed credentials.
- Entro Security classified 79.9% of the leaked material as SaaS and productivity tokens, showing that the campaign primarily targets reusable non-human access rather than application code.
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.
A: Stolen maintainer tokens turn a single compromise into a distribution problem.
Q: How do security teams spot NHI secret exposure before it becomes a wider incident?
A: Look for unexpected secret-scanning activity, abnormal repository creation, environment dumps, and installs that generate local credential artifacts.
Practitioner guidance
- Harden npm install-time execution Restrict lifecycle script execution in developer and CI/CD contexts where possible, and inventory which build paths still allow preinstall or install hooks to run with privileged environment access.
- Remove secrets from build-adjacent locations Move credentials out of code, config files, CI variables, and artifact stores so a compromised dependency cannot harvest a ready-made credential cache.
- Shorten token blast radius Replace reusable tokens with narrower-scoped credentials, reduce standing privileges, and invalidate any NHI credential that could publish packages or touch private repositories.
Bottom line: The core failure is not only malicious package code, but the presence of reusable NHI secrets in environments that npm install can reach.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/05/2026 8:17 pm
Install-time package execution is now an identity control point: The campaign shows that dependency trust alone is not enough if the installer can read the same secrets that production services use. npm lifecycle hooks run inside environments rich in NHI material, so the real governance question is what identity objects exist at install time, not just what code was fetched. Practitioners should treat package installation as a credential exposure boundary, not a software-only event.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams respond when a package ecosystem starts showing repeated credential theft?
A: They should assume the attacker is pursuing propagation, not a one-off compromise. Prioritise revocation of exposed credentials, review workflow and publishing permissions, and inspect repository mutation history for signs of cross-ecosystem spread. The fastest containment comes from cutting identity reuse paths before the malware can recurse into new environments.
👉 Read our full editorial: Shai Hulud 2.0 turns npm installs into NHI secret exposure