Notifications
Clear all
Topic starter
25/06/2026 12:50 am
TL;DR: Shai-Hulud spread through the npm ecosystem by harvesting static secrets from infected packages, then using stolen GitHub, npm, and cloud credentials to propagate further, according to Defakto Security. The incident shows that key rotation alone cannot contain a worm when permanent credentials still carry standing privilege and broad blast radius.
NHIMG editorial — based on content published by Defakto Security: Shai-Hulud npm supply chain attack analysis
By the numbers:
- Early reporting from Wiz, Sonatype, and Krebs put the number of infected packages around 180 to 200.
- Some outlets now put the total above 300, including CrowdStrike-maintained packages.
- Shai-Hulud compromised 300+ npm packages in days.
Questions worth separating out
Q: What breaks when static secrets are used in npm and CI/CD pipelines?
A: Static secrets break because they can be copied, reused, and replayed long after the original job completes.
Q: Why do static tokens increase lateral movement risk in software supply chains?
A: Static tokens increase lateral movement risk because they often authenticate across multiple tools, repositories, and cloud services.
Q: How do security teams know whether secret rotation is actually working?
A: Rotation is working only if stolen credentials become unusable quickly enough to prevent reuse.
Practitioner guidance
- Inventory every reusable credential in build and publish paths Map GitHub, npm, cloud, and CI/CD secrets to the jobs and repositories that can actually use them.
- Replace long-lived publish tokens with ephemeral workload identity Use runtime-issued identities for package publishing, deployment, and automation wherever the platform allows it.
- Separate secret scope from repository scope Do not allow one token to authenticate across multiple applications, packages, or tenants.
What's in the full article
Defakto Security's full article covers the operational detail this post intentionally leaves for the source:
- Package-by-package breakdown of how the worm moved through npm dependencies and post-install scripts
- Examples of the specific secret types the worm harvested, including GitHub, npm, Atlassian, and cloud credentials
- Discussion of why key rotation workflows add overhead without removing the underlying secret persistence problem
- Defakto's runtime identity approach for workloads and pipelines, including how ephemeral identities are issued and expired
👉 Read Defakto Security's analysis of the Shai-Hulud npm supply chain worm →
Static secrets in npm supply chains: what should teams change now?
Explore further
25/06/2026 9:52 am
Static credential persistence is the failure mode this worm exploited. The article shows that the issue was not token theft in isolation, but the fact that secrets remained valid, reusable, and spread across developer, CI/CD, and cloud environments. That is a governance failure, not a tooling quirk. The implication is that programmes built around static credential stewardship are managing the symptom after the compromise has already happened.
A few things that frame the scale:
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, creating unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: Who is accountable when a supply chain worm spreads through exposed secrets?
A: Accountability sits with the teams that own secret issuance, pipeline design, and repository access, not just with incident responders after the fact. Governance frameworks such as the NIST Cybersecurity Framework and OWASP Non-Human Identity Top 10 both point to access control, lifecycle management, and secure automation as shared responsibilities.
👉 Read our full editorial: Shai-hulud shows why static secrets still fuel supply chain worms
