Shai-Hulud 2.0 shows how NPM supply chain trust breaks down

At a glance

What this is: This is ArmorCode’s analysis of the Shai-Hulud 2.0 NPM supply chain attack, which abused trusted package installation paths to steal credentials and persist on developer systems.

Why it matters: It matters to IAM, PAM, and NHI practitioners because developer tokens, GitHub PATs, SSH keys, and cloud credentials behaved like high-value non-human identities with weak lifecycle control.

By the numbers:

• Between November 21 and 23, 2025, attackers compromised over 700 NPM packages in one of the largest supply chain attacks on record.
• 1, he malware is reported to have appeared at roughly 1,000 compromised repositories per hour at peak activity.

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

Context

Shai-Hulud 2.0 is a supply chain compromise, but the governance problem is identity and trust at build time. When package installation can execute code, developer workstations, CI runners, GitHub credentials, and cloud tokens all become part of the attack surface, and traditional dependency review is not enough to contain that risk.

The article also shows why NHI governance matters inside software delivery pipelines. Tokens, SSH keys, and runner identities can persist far longer than the code they are meant to support, which turns temporary development access into durable attacker infrastructure. That is a familiar failure pattern in modern supply chain incidents, not an isolated one.

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. That lets attacker-controlled scripts read memory, steal secrets, and potentially publish more malicious artifacts before defenders notice. The control that breaks is the assumption that dependency installation is operationally harmless. Treat install-time execution as a governed security boundary, not a routine developer convenience.

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. When those credentials are long-lived or broadly scoped, they become reusable access paths for attackers. Governance must cover ownership, scope, rotation, and offboarding just as it would for any other identity.

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. Unknown runner names, unusual workflow history, and persistent registration across reboots are warning signs. The key is to tie every runner to an owner, approved use case, and expiry.

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.

Technical breakdown

How malicious lifecycle scripts turn package installs into execution paths

In modern JavaScript ecosystems, package installation can trigger preinstall or postinstall scripts that run with the developer’s or CI system’s privileges. That means a dependency is not just code to be imported, but an execution vector during the install phase. In this campaign, the setup_bun.js script is the key mechanism: it lets the attacker run code before the package is even used, which collapses the line between software supply and runtime execution.

Practical implication: restrict lifecycle scripts in CI/CD and test dependency installation in isolated environments before allowing them into production pipelines.

Why credential harvesting works so well in developer environments

Developer systems accumulate secrets from many sources: NPM tokens, GitHub personal access tokens, SSH keys, cloud credentials, and session artifacts. Tools such as TruffleHog can rapidly search those locations and exfiltrate what looks like ordinary operational material but actually functions as a credential estate. Once harvested, those secrets often unlock source code, repositories, runners, and cloud services without triggering traditional malware detection.

Practical implication: treat developer endpoints and build agents as secret-bearing systems and enforce least-privilege, short-lived credentials across every toolchain.

How persistence on self-hosted runners extends the blast radius

The campaign used infected machines as self-hosted GitHub Actions runners, which creates an attacker-controlled execution surface inside the engineering environment. Because self-hosted runners can survive reboots and be reused across workflows, persistence is not limited to one malicious job. It becomes a foothold for ongoing command execution, repository manipulation, and follow-on credential theft, especially when runner identities are not tightly governed.

Practical implication: inventory and continuously validate runner identities, then revoke any runner that cannot be tied to a known, approved workload and lifecycle owner.

Threat narrative

Attacker objective: The attackers aimed to turn trusted software delivery infrastructure into a reusable foothold for credential theft, command execution, and destructive disruption.

1. Entry occurred through malicious NPM packages that executed during installation via setup scripts, turning dependency trust into initial code execution.
2. Credential harvesting followed as the malware scanned for NPM tokens, GitHub PATs, SSH keys, and cloud credentials on developer systems.
3. Escalation and persistence came from registering infected machines as self-hosted GitHub Actions runners named SHA1HULUD, giving attackers durable execution inside engineering workflows.
4. Impact included repository compromise, credential reuse, and destructive wiping of developer home directories when the malware detected it had been exposed.

NHI Mgmt Group analysis

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.

Persistent runner identities are a hidden NHI risk. Self-hosted runners are non-human identities in operational form, yet many organisations still manage them as disposable infrastructure. That assumption fails when the runner can survive reboot, execute arbitrary workflows, and retain access to repositories or secrets. The control gap is lifecycle governance for execution identities, not just patching or detection. Practitioners should inventory every runner as an identity with an owner, scope, and expiry.

Shai-Hulud 2.0 sharpens the case for the OWASP Non-Human Identity Top 10. Secret sprawl, overprivilege, and weak lifecycle controls all appear in this campaign, and they are the same governance failures that recur across NHI breaches. The article reinforces that dependency security and NHI security are converging disciplines, especially where developer tooling can reach cloud and source-control credentials. Practitioners should align supply chain controls with NHI governance rather than treating them as separate programmes.

Destructive payloads change the risk model for software supply chain attacks. The malware did not stop at credential theft; it also wiped data when detected, which raises the operational cost of delayed response. That shifts the question from simple compromise detection to blast-radius reduction, containment speed, and recovery readiness. Practitioners should assume supply chain compromise can now include sabotage, not just silent access.

Agentic AI features inside security workflows must be governed like other execution surfaces. The article notes AI-driven analysis and automation around exposure identification, and that matters because AI-assisted workflows often ingest the same secret-bearing repositories and logs that attackers target. When AI is used in incident triage or code analysis, access boundaries, auditability, and prompt-to-action controls need to be explicit. Practitioners should not let automation obscure who or what can see secrets.

What this signals

Secret sprawl is now an execution problem, not just a storage problem. When package managers, workflow engines, and developer endpoints can all expose credentials, the control objective shifts from vaulting secrets to governing every place those secrets can be used. Teams that still separate software supply chain security from identity governance will miss the joint failure mode. A useful framing is to treat developer tooling as a credential-bearing control plane, not just a delivery pipeline.

The practical signal for practitioners is that response speed now matters as much as prevention. If leaked secrets take weeks to remediate, attacker dwell time can easily outrun manual triage, especially when compromised packages are propagated through transitive dependencies. Teams should pair dependency controls with revocation automation, runner validation, and linked incident playbooks so that access loss happens faster than attacker reuse. The strongest alignment is with the OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix.

For practitioners

• 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. This directly reduces the chance that a package can execute arbitrary code during installation.
• 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. Revoke anything long-lived or unassigned, and tie each credential to a lifecycle record.
• 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. Search for suspicious runner names such as SHA1HULUD and remove any unknown instances immediately.
• Pin dependency versions and maintain an SBOM Lock dependencies to exact versions, track transitive packages in an SBOM, and compare installed components against approved baselines so compromised versions are visible quickly. This shortens the window between malicious publication and detection.
• Use short-lived credentials for build and release flows Replace long-lived tokens with short-lived, narrowly scoped credentials wherever possible, especially for package publication, repository access, and CI automation. That reduces reuse after theft and limits the attacker’s ability to pivot across tooling.

Key takeaways

• Shai-Hulud 2.0 shows that NPM package trust can be converted into code execution, credential theft, and durable access inside engineering workflows.
• The attack scale was large enough to affect more than 700 packages and 25,000 malicious repositories, which means exposure is a governance issue, not an isolated malware event.
• The control that matters most is lifecycle governance over build identities, secrets, and runners, because those are now part of the attack path.

Key terms

• Self-hosted runner: A CI/CD execution environment managed by the organisation rather than the platform vendor. It often has broad access to source, secrets, and deployment targets, which makes it a high-value persistence and exfiltration point if workflow controls are weak.
• Install-Time Script: An install-time script is code that executes when a package is installed, before the package has necessarily been validated in context. Attackers abuse these scripts because they can trigger silently in developer machines and CI systems, turning dependency installation into an execution path.
• Credential Estate: A credential estate is the full set of tokens, keys, certificates, and other authenticators an organisation uses across systems and workflows. It matters because compromise is rarely limited to one secret. Weak inventory, rotation, or ownership turns the estate into a reusable attack surface.
• Supply Chain Foothold: A supply chain foothold is an initial persistent access point created by compromising software distribution rather than the target system directly. It matters because one malicious update can create access across many endpoints, developer machines, or CI environments at once.

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

👉 ArmorCode's full blog covers the attack chain, compromise indicators, and immediate mitigation steps.

Deepen your knowledge

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 govern credentials, access, and lifecycle controls across modern identity programmes.