Shai-Hulud shows how npm worms turn one account into ecosystem risk

At a glance

What this is: This is ArmorCode's analysis of the Shai-Hulud npm supply chain worm and its rapid spread through compromised maintainer accounts, trusted publishing and malicious install-time hooks.

Why it matters: It matters because JavaScript dependency risk now sits at the intersection of supply chain security, secrets governance and IAM, where one stolen credential can cascade into ecosystem-scale exposure.

By the numbers:

• The attacker reached an estimated 2+ billion monthly installs after compromising more than 440 packages across 2,200+ package versions in under an hour.
• keyv had approximately 127M weekly downloads, while flat-cache and file-entry-cache had about 565M and 557M weekly downloads respectively.

👉 Read ArmorCode's analysis of the Shai-Hulud npm supply chain attack

Context

Shai-Hulud is a supply chain worm, which means the threat is not limited to one package or one maintainer account. It uses compromised credentials to republish malicious versions, then leverages install-time execution so the payload runs before teams can rely on application behaviour checks. For JavaScript programmes, that makes dependency trust, CI/CD secrets and publisher identity part of the same control surface.

The identity angle is direct: the attack abused maintainer access, npm tokens, GitHub credentials and cloud secrets to move from one account to many packages. That is why NHI governance, secrets handling and privileged access controls matter even when the incident presents as a software supply chain problem. The pattern is now familiar enough to be typical, not exceptional.

Key questions

Q: What breaks when a supply chain worm can use maintainer credentials to republish packages?

A: Package trust breaks at the identity layer first. If maintainers, CI pipelines or signing workflows can be compromised, the attacker can publish malicious versions that look legitimate and then spread them through normal dependency updates. The practical failure is not malware detection alone, but the absence of lifecycle control over publish-capable identities.

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. Once those secrets are exposed, the attacker can pivot from one package to many. That is why secrets hygiene, access scope and revocation speed matter as much as code scanning.

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. Useful signals include lockfile enforcement, release ageing, SBOM coverage across all shipped components and the speed of revocation for publish-capable identities. If a compromised package can still reach production in minutes, the controls are too weak.

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.

Technical breakdown

How a malicious preinstall hook turns a clean package into a delivery vector

The key trick in Shai-Hulud is that the package's visible library code can remain unchanged while the install path becomes malicious. A preinstall script runs before the package is fully installed, which lets the attacker execute setup.mjs before application runtime begins. Because the attack chain is embedded in package metadata, diffing dist output alone will miss it. Trusted publishing and valid provenance can also reduce suspicion if the CI/CD identity used to sign the release has already been compromised.

Practical implication: inspect package metadata, install scripts and provenance together, not just the compiled library contents.

Why stolen npm and GitHub credentials let a worm self-propagate

Once the attacker captures publish-capable identities, the package becomes a replication mechanism. The compromised maintainer account can publish a new version, inject the malicious hook, and then repeat the process across additional packages the identity is authorised to update. This is an identity problem as much as a supply chain problem, because the worm is using standing privilege and trust delegation to move laterally through the ecosystem. The scale comes from credential scope, not malware sophistication alone.

Practical implication: reduce publish rights, scope tokens tightly and revoke standing package maintainer access wherever possible.

How persistence and exfiltration survive in developer environments

Shai-Hulud adds persistence by writing autostart hooks into developer tooling files such as .claude/settings.json and .vscode/tasks.json, then exfiltrates secrets through attacker-controlled GitHub repositories and fallback channels. That combination matters because developers and CI runners often contain the very credentials needed to continue propagation. Once those secrets are harvested, the attacker can pivot into cloud, Kubernetes and secrets-management systems. The control gap is usually lifecycle governance over developer and machine identities, not a single missed alert.

Practical implication: monitor developer workspaces and CI runners as privileged identity zones, with strict secret exposure and revocation controls.

Threat narrative

Attacker objective: The attacker aimed to turn one compromised maintainer account into a self-replicating distribution channel for credential theft and broad downstream package compromise.

1. Entry occurred when the attacker hijacked a maintainer identity and pushed malicious changes into package repositories used across the JavaScript ecosystem.
2. Credential access followed as the worm harvested npm tokens, GitHub credentials, cloud secrets, Kubernetes tokens, Vault tokens and SSH keys from developer machines and CI/CD runners.
3. Escalation and lateral movement happened when stolen publish rights were used to republish infected versions into additional packages with valid provenance.
4. Impact was ecosystem-scale exposure, with more than 440 packages compromised and attacker-controlled exfiltration of sensitive credentials.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Trusted publishing can become trusted compromise when the signing identity is already lost. Valid provenance does not help if the release pipeline or maintainer account is the thing under attack. This is the governance gap: organisations often validate artefacts but not the identities that produced them. Teams should verify who can sign, who can publish and how quickly those rights can be removed.

Secret harvesting from developer tooling creates a machine-identity spillover effect. Once tokens, cloud keys and Kubernetes credentials are stolen from workstations or runners, the attacker can move into infrastructure far beyond npm. That links software supply chain risk to IAM and PAM because machine identities often inherit excessive standing privilege. Practitioners should govern developer and runner secrets as production-grade identities, not convenience credentials.

Dependency cooldowns and lockfile discipline are now blast-radius controls. When a worm can propagate in under an hour, the question is not only whether you detect compromise, but whether your consumption model slows it down. This is where version pinning, release ageing and SBOM visibility intersect with identity controls. Teams should measure how quickly a malicious release could reach production in their own pipeline.

Shai-Hulud reinforces that NHI security is a lifecycle problem, not a point-in-time review problem. The compromised identities in this case had enough standing trust to publish, persist and exfiltrate before responders could intervene. That is exactly the class of failure OWASP NHI guidance is meant to reduce. Practitioners should remove standing privilege wherever package publishing or automation identity is involved.

From our research:

• 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.
• That speed makes continuous secrets governance and rapid revocation the practical difference between containment and ecosystem spread, as explored in 52 NHI Breaches Analysis.

What this signals

Shai-Hulud shows that supply chain defence now depends on how quickly organisations can identify and revoke publishing identities, not just how well they scan dependencies. A malicious package can be technically small but operationally huge when a single maintainer account or CI token has broad release authority.

Publish identity sprawl: when package maintainers, automation tokens and release pipelines are not governed as a single identity estate, attackers can move from one compromised account to an entire dependency tree. That is the pattern teams should watch for in npm, PyPI and container registries alike.

For practitioners, the next control question is whether your software delivery model can absorb a trusted release turning hostile in minutes. If the answer depends on manual triage, the programme is already operating slower than the threat.

For practitioners

• Audit package publishing identities and tokens Inventory every maintainer account, npm token and GitHub identity that can publish packages or modify release workflows. Revoke broad access, rotate credentials after any suspected compromise and require explicit owner mapping for each publish-capable identity.
• 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. Add policy checks that flag packages whose metadata changes but whose library code appears unchanged.
• Tighten CI/CD and runner secret exposure Treat developer workstations and build runners as privileged zones. Restrict access to npm tokens, cloud keys, Kubernetes credentials and Vault secrets, and remove plaintext secrets from local files and workflow state wherever possible.
• Use release ageing and dependency cooldowns Delay adoption of fresh package versions until they have passed an internal review or ageing period. This reduces the chance that a malicious release can reach production before detection and containment controls activate.
• Map exposure with continuous SBOM monitoring Continuously reconcile your software bill of materials against compromised package lists and version ranges. Prioritise applications that include keyv, flat-cache or related transitive dependencies, then tie findings to remediation owners immediately.

Key takeaways

• Shai-Hulud is a supply chain worm that turns maintainer identity into a distribution channel for compromise.
• The campaign reached billions of installs because trusted publishing, secrets exposure and rapid republishing were all available to the attacker.
• The most effective controls are lifecycle controls over publish identities, secret scope, dependency ageing and SBOM visibility.

Key terms

• Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Publish-Capable Identity: A publish-capable identity is any human or machine account that can release software artefacts to a package registry or code repository. These identities carry high blast radius because compromising them lets an attacker replace trusted software with malicious versions.
• Dependency blast radius: Dependency blast radius is the amount of service impact created when a lower-level component fails. In identity-aware systems, it describes how far a resolver, proxy library, or sidecar defect can propagate before it disrupts authentication, authorisation, or session continuity.

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

👉 ArmorCode's full post covers the attack chain, indicators of compromise and saved-view triage details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to connect identity controls to broader security operations and resilience.