Shai-Hulud 2.0 shows how npm supply chains expose cloud identity risk

At a glance

What this is: This is an analysis of the Shai-Hulud 2.0 npm supply chain attack and its cloud identity impact, showing how malicious packages harvested credentials and secrets at scale.

Why it matters: It matters because IAM, PAM, and NHI teams have to treat build-time dependency trust, credential scope, and secret exposure as one blast-radius problem, not separate controls.

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

Context

Shai-Hulud 2.0 is a supply chain compromise with an identity problem at its core. Malicious npm packages executed during installation, harvested cloud credentials and automation secrets, and pushed stolen data into attacker-controlled GitHub repositories.

The governance gap is not just package integrity. When build systems, developer laptops, and CI/CD runners all hold reusable secrets, a single malicious dependency can turn software delivery into credential collection and downstream cloud account abuse.

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 standing CI/CD tokens create so much risk in supply chain attacks?

A: Standing tokens remain usable long after the moment they were created, so a compromise can persist through normal operations and even through partial remediation. In supply chain environments, that means one stolen token can be reused to push artefacts, alter tags, or seed downstream packages. Short-lived access and verifiable revocation are the controls that reduce that exposure.

Q: How do teams know if a dependency compromise has become a persistence problem?

A: Look for unrecognised self-hosted runners, unexpected workflows, new branches, repeated secret access, and tokens being used from places they should never reach. Those signals show the incident has moved from one-off execution into ongoing control of the delivery environment.

Q: How should teams respond when a malicious npm package can steal build secrets?

A: Treat the package as a credential exposure event, not just a dependency incident. Revoke and rotate every secret that the affected build environment could access, then inspect GitHub, CI runners, and secret manager logs for abnormal access, repository creation, and unexpected automation artefacts.

Technical breakdown

How malicious npm preinstall hooks turn dependency installs into code execution

npm packages can execute lifecycle scripts during install, including preinstall, before the package is fully trusted by the developer or pipeline. In this incident, that meant the malware ran as soon as affected environments installed the package, which made ordinary dependency resolution the entry point for execution. The technical issue is not npm alone but the trust model around package installation: build systems often assume a dependency is inert until reviewed, while lifecycle hooks let code run before that review ever happens. Practical implication: restrict lifecycle script execution in build and CI contexts where the dependency source is not fully governed.

Practical implication: disable or tightly gate lifecycle scripts in build and CI environments that process untrusted dependencies.

Why credential and secret harvesting is the real cloud identity failure

The malware did not need to break cloud controls directly if it could steal the identities those controls trusted. It scraped cloud keys, GitHub tokens, metadata tokens, CI/CD variables, SSH keys, and configuration files, then reused them across environments. That is classic NHI exposure: the problem is not only that secrets existed, but that they were reusable, broadly scoped, and available in places where software installation could read them. Practical implication: reduce the number of credential surfaces reachable from build and developer contexts, and make access tokens less portable across environments.

Practical implication: reduce credential surfaces in build and developer contexts and limit token portability across environments.

How stolen tokens become persistence, propagation, and cloud account abuse

Once the malware had valid tokens, it used them to create repositories, register self-hosted runners, enumerate secrets, and republish tampered packages. That sequence shows how identity abuse compounds: one stolen token can become multiple persistence points, broader package reach, and cross-account reuse. The cloud risk is not confined to exfiltration. Reused access also enables role assumption, secret store access, and privilege spread that can outlive the original malware execution. Practical implication: treat leaked CI/CD, npm, and GitHub tokens as a propagation vector, not a single compromised secret.

Practical implication: treat leaked CI/CD, npm, and GitHub tokens as a propagation vector and remove persistence paths quickly.

Threat narrative

Attacker objective: The attacker’s objective was to harvest reusable cloud and automation identities, then turn one package compromise into broad downstream access and persistence.

1. Entry occurred through malicious npm package versions that executed during installation and reached developer machines and CI/CD systems without a separate login step.
2. Credential access followed as the payload scraped cloud keys, GitHub tokens, CI/CD variables, metadata tokens, SSH keys, and local configuration files.
3. Escalation and persistence came from token reuse, self-hosted runner registration, secret enumeration workflows, and republishing compromised packages to expand reach.
4. Impact was widespread cloud identity exposure, attacker-controlled repositories full of stolen data, and a reusable credential set that could be abused across environments.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

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

NHI Mgmt Group analysis

Package trust is now an identity problem, not a code-review problem: the moment a dependency can execute during install, package provenance stops being the only boundary that matters. In this campaign, npm delivery became a credential collection mechanism because build and developer contexts already contained usable cloud and automation secrets. The practitioner conclusion is simple: identity posture now determines the blast radius of dependency risk.

Secrets in build paths create identity reuse debt: cloud keys, GitHub tokens, CI/CD variables, and metadata tokens were all reachable from environments that assumed installation-time code would be benign. That is not a hygiene detail, it is a governance failure in how access is distributed across software delivery. The implication is that credential scope and placement must be designed around what build-time code can actually read.

Self-hosted runners and workflow artefacts extend compromise beyond the initial package: the article shows how stolen tokens were used to register runners, enumerate secrets, and push data into GitHub infrastructure. That turns a dependency compromise into a persistence problem across the delivery platform. Practitioners should read this as a boundary collapse between CI/CD operations and identity governance.

Blast radius control is the decisive control plane for supply chain identity risk: the same malicious package had very different effects depending on whether exposed identities were long-lived, overprivileged, or shared across environments. The article makes clear that privilege shape, not just detection speed, determines how far a supply chain incident can spread. The practitioner conclusion is to govern which identities can exist at install time, not just which packages are approved.

Shai-Hulud 2.0 is a warning about credential portability across environments: the same stolen token set could be reused across developer laptops, CI systems, cloud accounts, and GitHub workflows because identity boundaries were too loose. That creates an identity blast radius that spans the software supply chain. The practitioner conclusion is to treat every environment that can see a secret as part of the same governance domain.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius is now a supply chain control problem: when build systems, developer endpoints, and cloud accounts all share credential exposure paths, a malicious package can reuse one token set across several environments. The practical shift is to treat secret placement and token scope as delivery infrastructure, not just IAM housekeeping.

Short-lived credentials matter because install-time malware does not wait for review cycles: once a dependency can execute during installation, every long-lived secret reachable from that context becomes reusable. 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. according to the Ultimate Guide to NHIs

For practitioners

• Restrict install-time script execution Block or tightly gate npm lifecycle scripts in CI/CD and other build systems that process unvetted dependencies, especially where secrets are present.
• Inventory exposed cloud and GitHub credentials Map every cloud key, GitHub token, CI/CD credential, npm token, and SSH key reachable from build and developer contexts, then revoke anything that was exposed.
• Replace reusable secrets with short-lived scoped credentials Remove long-lived secrets from pipelines and local developer environments, and move to short-lived credentials with tight scope wherever installation-time code can run.
• Hunt for persistence in GitHub and CI/CD Review repositories for unrecognised workflows, self-hosted runners, suspicious branches, and artefacts tied to Shai-Hulud-style exfiltration.
• Tighten third-party package governance Pin dependency versions, limit network access in build jobs, and validate package provenance before any install step can reach credentials or metadata services.

Key takeaways

• The incident shows that npm supply chain compromise can become cloud identity abuse when build environments expose reusable secrets.
• More than 25,000 attacker-controlled repositories were used to store stolen data, which indicates broad credential harvesting rather than isolated malware execution.
• The control that matters most is reducing credential reach during install time, because package trust alone does not contain the blast radius.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• 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.
• 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.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The exact malware behaviour across preinstall, exfiltration, runner registration, and republishing steps
• The list of credential types harvested from developer and CI/CD environments
• The GitHub artefacts, workflow tricks, and repository patterns used to hide stolen data
• The post-incident cleanup actions for revoking tokens and checking for persistence

👉 Unosecur's full post covers the attack chain, credential exposure scope, and cloud identity implications.

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.