Notifications
Clear all
Topic starter
18/08/2026 2:30 pm
TL;DR: A Shai-Hulud npm worm compromised keyv, flat-cache and 440+ packages, then self-propagated through stolen credentials and trusted publishing flows to reach more than 2 billion monthly installs, according to ArmorCode. The incident shows that package integrity checks are not enough when CI/CD credentials, provenance and rapid release pipelines are all in play.
NHIMG editorial — based on content published by ArmorCode: Shai-Hulud Returns: Detecting the npm Supply Chain Attack Behind keyv, flat-cache, and 440+ Compromised Packages
By the numbers:
- keyv had approximately 127M weekly downloads, while flat-cache and file-entry-cache had about 565M and 557M weekly downloads respectively.
Questions worth separating out
Q: What breaks when a supply chain worm can use maintainer credentials to republish packages?
A: Package trust breaks at the identity layer first.
Q: Why do npm supply chain attacks become broader when secrets are stored in developer workspaces?
A: Developer machines and CI runners often hold the credentials needed to continue propagation, including cloud keys, GitHub tokens and package publish rights.
Q: How do security teams know if dependency controls are actually limiting blast radius?
A: Look for evidence that malicious releases are slowed by policy, not just detected later.
Practitioner guidance
- Audit package publishing identities and tokens Inventory every maintainer account, npm token and GitHub identity that can publish packages or modify release workflows.
- Block install-time execution paths Detect and review preinstall, postinstall and lifecycle scripts in third-party packages, especially where dependencies are newly released or unusually modified.
- Tighten CI/CD and runner secret exposure Treat developer workstations and build runners as privileged zones.
What's in the full article
ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step detection workflow for the Shai-Hulud package family across connected scanners and SBOM views
- Example queries for Ask Anya that map exposure by application, component and severity
- Indicator of compromise table with file names, hashes, process patterns and fallback exfiltration endpoints
- Saved-view structure for triage across Findings and SBOM pages when packages are already in your estate
👉 Read ArmorCode's analysis of the Shai-Hulud npm supply chain attack →
Shai-Hulud npm worm risk: what security teams need to do now?
Explore further
18/08/2026 3:17 pm
Shai-Hulud is best understood as identity-enabled supply chain propagation, not just malware distribution. The attack only scales because publish rights, maintainer credentials and CI/CD trust were already acting as implicit infrastructure. That means the control problem sits in NHI governance, secrets handling and pipeline identity, not only in dependency scanning. Practitioners should treat package publishing rights as high-risk identities with full lifecycle control.
A few things that frame the scale:
- The attacker reached an estimated 2+ billion monthly installs after compromising more than 440 packages across 2,200+ package versions in under an hour, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
A question worth separating out:
Q: Who is accountable when a compromised maintainer credential exposes downstream environments?
A: Accountability sits with the teams that own token lifecycle, publishing policy, and secrets governance, not just with the maintainer whose identity was stolen. In practice, this spans platform engineering, security architecture, and application owners because the attack abuses organisational trust in the software delivery chain.
👉 Read our full editorial: Shai-Hulud shows how npm worms turn one account into ecosystem risk
