Shai-Hulud 2.0 shows how npm supply chain attacks steal identities

At a glance

What this is: This analysis of Shai-Hulud 2.0 shows how npm supply chain compromise turns development pipelines into identity-theft channels through lifecycle hooks, cloud token theft, workflow abuse, and SCM persistence.

Why it matters: It matters because IAM, PAM, and NHI governance all have to extend into build systems, where developer and workload identities can be harvested faster than traditional reviews or rotations can react.

Context

Shai-Hulud 2.0 is a supply chain attack on the software development lifecycle, not just on code integrity. The core problem is that build and installation steps still execute with trusted identity context, even when the package being installed is untrusted.

That creates a governance gap for IAM and NHI programmes. Developer tokens, cloud role credentials, CI runner permissions, and SCM access can all be reachable during routine package installation, which means compromise can begin before normal security controls or review gates have a chance to act.

Cymulate's analysis also shows why build systems now sit inside identity governance scope. Once an attacker can steal workflow secrets, cloud metadata tokens, or runner credentials, the pipeline itself becomes a distribution and persistence layer for further identity abuse.

Key questions

Q: What breaks when npm lifecycle hooks are allowed to run unreviewed in CI/CD?

A: The package installation step becomes a code execution boundary rather than a dependency retrieval step. Attackers can trigger scripts before normal inspection finishes, which means malicious code can harvest secrets or alter workflows before defenders notice. The practical failure is trusting install-time behavior from packages that have not been validated for execution.

Q: Why do build runners make supply chain compromise so much worse?

A: Build runners often sit close to source control, cloud metadata, artifact signing, and secret stores, so one compromise can expose several identity domains at once. If those permissions are broad, an attacker can move from a single package execution into cloud access, repository control, and persistence through automation. The risk comes from identity reach, not just host compromise.

Q: What are the warning signs that a repository or runner has been abused for persistence?

A: Look for unexpected workflow creation, new self-hosted runners, suspicious artifact uploads, unusual secret access patterns, and repository changes that appear to come from automation rather than a known maintainer. Those signals indicate that the attacker is using trusted SCM mechanisms to keep access alive. Persistence in this context often looks like legitimate automation.

Q: How should teams govern build-time identities differently from human user accounts?

A: Build-time identities need much narrower scope, tighter secret exposure limits, and stronger controls around what they can read, write, and execute during a task. They should be treated as ephemeral operational identities, not as lightweight human proxies. The key distinction is that a build identity should be able to complete one job without becoming a reusable access path.

Technical breakdown

How npm lifecycle hooks create the initial execution path

npm packages can define lifecycle scripts such as preinstall and postinstall in package.json, and those scripts run during package installation. In Shai-Hulud 2.0, that mechanism is the entry point: malicious JavaScript executes before normal layout or trust inspection finishes, which means the code runs inside the developer or CI context that invoked npm install. The important technical detail is timing. The attacker does not need the package to be imported or exercised later. The install step itself becomes a code execution event, which is why SDLC trust has to be treated as an access control problem, not just a software delivery one.

Practical implication: block or tightly govern install-time script execution for untrusted packages and inspect package manifests before build-time code runs.

How build-time identity theft pivots through cloud metadata and secrets

The malware does not stop at local execution. Cymulate describes collection of GitHub PATs, repository secrets, cloud vault material, and metadata-derived credentials from IMDS or equivalent services. That matters because CI/CD runners and build containers often inherit broad access to secret stores, source control, and cloud APIs. Once the attacker obtains temporary role credentials, the compromise can move from a single runner to cloud resources and secret backends. This is an identity chain, not a simple malware chain: each credential source increases the blast radius because the build system already has legitimate pathways into production-adjacent services.

Practical implication: treat build-time cloud access as a scoped identity tier and inventory every secret source reachable from runners and developer machines.

How SCM persistence turns stolen identity into durable access

The campaign uses GitHub workflow injection, discussion-based backdoors, self-hosted runner registration, and public repository exfiltration to keep access alive after the initial install event. That persistence layer is especially dangerous because it blends normal developer workflow mechanics with attacker-controlled automation. The attacker is not just stealing data; it is embedding future execution paths into the SCM and CI control plane. Once those objects exist, the malicious identity can re-enter through trusted automation rather than repeating the original compromise path. The result is durable access with low operator visibility.

Practical implication: govern workflow creation, runner registration, and repository-level automation with the same rigor you apply to privileged access.

Threat narrative

Attacker objective: The attacker wants durable, credentialed access to developer, CI/CD, SCM, and cloud identities so the supply chain can be reused as an exfiltration and persistence channel.

1. Entry occurs when a developer or CI pipeline installs a trojanised npm package that triggers malicious lifecycle scripts during installation.
2. Credential access follows when the payload harvests GitHub tokens, workflow secrets, cloud metadata credentials, and repository secrets from the build environment.
3. Persistence and lateral movement occur when the attacker injects workflows, registers a self-hosted runner, and uses stolen credentials to reach cloud and SCM systems.
4. Impact is achieved when the attacker exfiltrates secrets, maintains remote execution, and expands the compromise across the codebase and cloud estate.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
• axios npm compromise 2026: North Korea-linked UNC1069 hijacked an axios maintainer's npm account to ship a backdoor that bots pulled into public repos within minutes.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build pipelines are now identity systems, not just delivery systems. Shai-Hulud 2.0 shows that package installation can execute with meaningful trust, privilege, and secret access. That means the security boundary has moved into the SDLC, where developer identity, runner identity, and cloud identity all intersect. Practitioners should stop treating CI/CD as an adjacent system and start treating it as an identity plane with its own governance model.

Lifecycle hooks are an attack surface because they collapse the gap between retrieval and execution. npm preinstall and postinstall hooks let an attacker run code at the exact moment the package is being trusted. That is not merely a software weakness. It is a governance failure in which install-time execution is granted before the package can be fully assessed. The practical conclusion is that runtime trust decisions cannot be deferred until after installation.

Ephemeral build access does not equal low risk when secrets and cloud roles are exposed. The campaign harvests temporary credentials, vault material, and SCM tokens precisely because build systems are allowed to touch them during normal operation. Shai-Hulud 2.0 turns short-lived access into a high-speed exfiltration path, proving that privilege duration is less important than privilege reach. The governance question is not how long access lasts, but how much identity material is reachable during the task.

SCM persistence creates identity blast radius across later builds. Once the attacker can create workflows, register runners, or publish artifacts from stolen credentials, the compromise no longer depends on the original malicious package. A compromised repository becomes a reusable trust anchor for future execution. That is why source control hygiene, runner governance, and secret containment now belong in the same control conversation.

Identity blast radius is the right concept for supply chain compromise. The article makes clear that one package install can expose developer tokens, cloud metadata credentials, workflow secrets, and repository automation in a single chain. That is a different problem from generic malware because the attacker is not looking for one host. It is looking for every identity boundary the build process can touch. Practitioners should map which identities a build step can reach before they assume isolation exists.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity blast radius: Shai-Hulud-style attacks matter because one compromised install path can expose developer tokens, cloud credentials, and SCM automation in the same chain. Teams should map which identities their build systems can reach before treating the pipeline as isolated.

The right control question is no longer whether CI/CD is trusted, but which secrets and roles it can touch while a package is being installed. That shifts governance from after-the-fact detection toward task-scoped access design and repository-level control.

Build systems that can register runners, create workflows, or query cloud metadata are already acting inside the identity plane. Security programmes need to model those permissions as governed access paths, not as incidental platform features.

For practitioners

• Restrict install-time script execution Block or review package lifecycle scripts in build and developer contexts so preinstall and postinstall hooks cannot run unchecked from untrusted dependencies.
• Reduce cloud identity reach from runners Limit which cloud roles, metadata endpoints, and secret stores CI/CD runners can query so a compromised build task cannot pivot into broader cloud access.
• Harden SCM automation and workflow creation Require approval and monitoring for new workflows, self-hosted runner registration, and repository-level automation that can execute in trusted namespaces.
• Separate build secrets from production secrets Use narrowly scoped credentials for build systems and keep repository, cloud, and signing secrets outside default runner environments wherever possible.

Key takeaways

• Shai-Hulud 2.0 demonstrates that npm supply chain attacks now target identity material inside the build process, not only source code integrity.
• The campaign shows how workflow injection, cloud metadata theft, and SCM persistence can widen one compromise into a multi-system identity event.
• Controls for package execution, runner scope, and secret exposure have to move into the same governance discussion as privileged production access.

Key terms

• Lifecycle Hook: A lifecycle hook is code that runs automatically at defined stages of package installation or build processing, such as preinstall or postinstall. These hooks are powerful because they can execute before deeper inspection or controls are applied, making them a common abuse path in supply chain attacks.
• Cloud Identity Pivot: A cloud identity pivot occurs when an attacker moves from a compromised host or runner into temporary cloud credentials or role-based access. The pivot matters because the original host compromise becomes a route into broader infrastructure, often through metadata services or token caches.
• SCM Persistence: SCM persistence is the use of source control and repository automation to keep attacker access alive after the first compromise. It can include malicious workflows, runner registration, or artifact abuse, all of which let the attacker re-enter through systems the organisation still trusts.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.