Notifications
Clear all
Topic starter
20/08/2026 5:43 pm
TL;DR: The Shai-Hulud 2.0 campaign compromised over 700 NPM packages, created 25,000+ malicious repositories across 350+ GitHub accounts, and used package-install scripts to steal tokens, keys, and cloud credentials while maintaining persistence, according to ArmorCode. The case shows that software supply chains now need identity-aware controls, not just dependency scanning.
NHIMG editorial — based on content published by ArmorCode: Shai-Hulud 2.0 Malware Hits NPM: is Your Organization Exposed?
By the numbers:
- 1, he malware is reported to have appeared at roughly 1,000 compromised repositories per hour at peak activity.
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 developer tokens and keys behave like non-human identities?
A: Because they authenticate systems, not people, and they often persist across pipelines, repositories, and cloud services.
Q: How do security teams know if self-hosted runners are operating outside policy?
A: Look for runners that appear without approval, survive beyond their intended workload, or execute jobs unrelated to their assigned purpose.
Practitioner guidance
- Restrict package lifecycle script execution Disable or tightly control preinstall and postinstall scripts in CI/CD, and only allow them in isolated review environments where dependency behaviour is observable before merge.
- Treat developer credentials as an NHI estate Inventory NPM tokens, GitHub PATs, SSH keys, cloud credentials, and runner tokens as governed non-human identities with owners, scopes, and expiry.
- Continuously validate self-hosted runners Require attestation, naming controls, and approval records for every self-hosted GitHub Actions runner, then retire runners that cannot be linked to a known workload.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- Package-specific indicators of compromise, including the repository naming patterns and workflow artefacts associated with Shai-Hulud 2.0
- Step-by-step hunting guidance for checking whether your environment contains the affected NPM packages or compromised GitHub runners
- ArmorCode's exposure-detection workflow for correlating open-source package data with findings across an organisation's environment
- Practical recovery guidance for teams that need to review GitHub Actions history, repository commits, and affected developer endpoints
👉 Read ArmorCode's analysis of the Shai-Hulud 2.0 NPM supply chain attack →
Shai-Hulud 2.0 supply chain attack: what are teams missing?
Explore further
20/08/2026 6:26 pm
Trusted build paths have become identity paths. This attack worked because package installation, workflow execution, and runner registration were all treated as routine engineering functions rather than governed access channels. Once tokens, keys, and runner identities are part of that path, the supply chain becomes an identity problem as much as a software integrity problem. Practitioners should govern build-time trust with the same seriousness they apply to privileged access.
A question worth separating out:
Q: What should organisations do immediately after a supply chain secret theft event?
A: Contain the execution surface first by revoking exposed tokens, disabling suspicious runners, and isolating affected build systems before the attacker can reuse stolen credentials. Then rotate secrets, validate repository integrity, and review workflow history for unauthorised commits or discussions. Recovery is slower if the execution path remains open.
👉 Read our full editorial: Shai-Hulud 2.0 shows how NPM supply chain trust breaks down
