Shai-Hulud 2.0 turns npm installs into a secrets exfiltration channel

At a glance

What this is: This is an analysis of the Shai-Hulud 2.0 npm supply chain attack, which used malicious package installs to exfiltrate cloud credentials, GitHub tokens, and CI/CD secrets at scale.

Why it matters: It matters because CI/CD pipelines, developer environments, and package trust chains are now identity attack surfaces, so leaked secrets can become reusable access across cloud and code systems.

By the numbers:

• The attack ran between November 21 and 23, 2025.

👉 Read Unosecur's analysis of the Shai-Hulud 2.0 npm secrets exfiltration campaign

Context

Shai-Hulud 2.0 is a supply chain compromise that turns a routine npm install into a credential theft event. The security gap is not just malicious code in dependencies, but the trust model that lets package execution touch secrets, tokens, and pipeline credentials during installation.

For identity teams, the core issue is that CI/CD systems and developer workstations often hold reusable non-human identity material such as cloud keys, GitHub tokens, and automation secrets. Once those credentials are harvested, the attacker is no longer limited to the original package infection path.

The article’s evidence points to a wider governance failure: build systems are still being treated as software delivery infrastructure first and identity environments second. That assumption is increasingly out of date in modern software supply chains.

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 CI/CD secrets create more risk than many teams expect?

A: CI/CD secrets often have broad blast radius because they can authenticate to source control, cloud platforms, package registries, and deployment systems. If those secrets are long-lived or reused across repositories, one exposure can open several downstream paths. The risk is highest when secrets are stored in workflow contexts where third-party code can read them.

Q: What are the signs that a software supply chain attack through GitHub may already be in progress?

A: Warning signs include unsolicited contact from unfamiliar accounts, invitations to collaborate on suspicious projects, requests to clone and run external repositories, and unexpected package installs during execution. Security teams should also watch for unusual GitHub log activity, unfamiliar NPM dependencies, and endpoints that begin calling remote systems after code is run. Those signals suggest the trust boundary has already been crossed.

Q: Should teams prioritise secret rotation or build hardening after an npm worm event?

A: They should do both, but rotation comes first for any credential that may already have been exposed. Build hardening reduces the chance of repeat compromise, while rotation cuts off immediate reuse paths across cloud, GitHub, and automation systems. If you delay rotation, the attacker keeps the highest-value part of the breach.

Technical breakdown

Pre-install script execution turns package trust into code execution

npm lifecycle hooks, especially pre-install scripts, run before the package is fully trusted or inspected by the developer. That means package installation can execute attacker-controlled code in the same runtime context as CI workers or developer laptops. In this attack, the malicious payload used that early execution point to begin credential harvesting immediately, before conventional reviews or scanning would necessarily trigger. The technical weakness is the assumption that package install is a passive retrieval step. In practice, it is an execution event with access to local environment variables, cached credentials, and filesystem artifacts.

Practical implication: treat dependency installation as executable code with secret-access risk, not as a harmless fetch step.

Credential harvesting succeeds because build and developer environments hold NHI secrets

The malware scraped cloud keys, GitHub tokens, CI/CD variables, metadata tokens, SSH keys, and configuration files, then packaged the results into JSON for exfiltration. This is a classic non-human identity problem because the attacker is targeting machine-usable credentials rather than user passwords. When those secrets are long-lived or broadly scoped, the attacker can reuse them across cloud accounts, GitHub, and automation systems without needing fresh compromise at each step. The result is a large blast radius created by secret reuse and broad privilege scope, not by one isolated infected package.

Practical implication: map where machine credentials live outside secret managers and revoke broad, reusable tokens first.

GitHub becomes both the exfiltration sink and a persistence layer

The campaign used stolen tokens to create attacker-controlled repositories, upload harvested data, and register infected machines as self-hosted runners. It also planted workflows that could execute on discussion events, which turns GitHub infrastructure into a control channel, not just a storage location. This is important because the attacker is not only stealing secrets, but also converting legitimate platform features into persistence and repeat access. The technical pattern combines token abuse, repository sprawl, and workflow abuse into one feedback loop that is difficult to unwind if identity hygiene is weak.

Practical implication: audit GitHub for rogue runners, unexpected workflows, and token reuse after any npm supply chain compromise.

Threat narrative

Attacker objective: The attacker aimed to steal reusable machine credentials, then use them to persist across GitHub, CI/CD, and cloud environments while widening the compromise.

1. Entry occurred when malicious npm package versions were pulled through normal installation workflows and executed during the pre-install phase.
2. Credential harvesting followed as the malware scraped cloud keys, GitHub tokens, CI/CD secrets, metadata tokens, SSH keys, and local configuration files.
3. Escalation and persistence came from using stolen tokens to create attacker-owned repositories, register self-hosted runners, and push workflows that could keep executing through GitHub events.
4. Impact was the reuse and redistribution of stolen identities across cloud and code systems, expanding blast radius and enabling follow-on compromise.

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.
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

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

Secrets sprawl is now a supply chain exposure problem, not just a vaulting problem. This campaign shows that credentials stored in CI/CD variables, local config files, and developer environments remain reachable to malicious package code long before a vault control can help. The governance gap is where build-time execution still has access to identity material that should have been isolated from package installation. Practitioners need to treat secret placement as part of software supply chain risk management, not as an afterthought.

Package installation has become an identity event. The article demonstrates that npm install can trigger code with direct access to machine credentials, environment tokens, and cloud metadata. That means the security question is no longer only whether the package is malicious, but whether the runtime context should ever contain reusable secrets in the first place. For identity governance, this collapses the boundary between software delivery and non-human identity control.

Identity blast radius, not compromise count, is the meaningful metric here. More than 25,000 repositories were used to store stolen data, and the malware repeatedly reused available credentials to widen access. That pattern shows why security teams must measure how far a leaked token can travel across GitHub, cloud, and CI/CD trust relationships. The right focus is containment of reuse paths, because the attacker gains leverage from interoperability between identities.

Short-lived trust windows are a stronger control concept than static secret protection alone. The attack succeeds because many environments still assume a credential can survive long enough to be reviewed, rotated, and contained after exposure. In practice, build systems need controls that shrink the window between credential issuance and use, because once secrets are present during install, the exposure path is already open. That is a governance problem as much as a technical one.

Third-party package trust now belongs in NHI governance. This is not only a software integrity issue. When packages can execute in environments holding cloud and automation secrets, the package ecosystem becomes part of the identity attack surface, and offboarding, rotation, and scoping decisions must extend across build tooling, not stop at the secrets manager. Practitioners should reclassify dependency trust as identity risk with supply chain characteristics.

From our research library:

• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius is now the operational measure that matters most. A package compromise that can touch cloud keys, GitHub tokens, and CI/CD secrets no longer behaves like a simple software supply chain event. It becomes a cross-domain identity incident, which means governance has to follow the credential wherever it can be reused.

Secret placement is the control point, not just secret rotation. According to the Ultimate Guide to NHIs, 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That makes install-time exposure predictable, not exceptional, and shifts the priority to removing secrets from places package code can reach.

For practitioners

• Remove install-time secret exposure from build paths Keep cloud keys, GitHub tokens, and CI/CD credentials out of environments where npm lifecycle scripts can execute. Use scoped, short-lived credentials and isolate build jobs from secrets that are not strictly required at install time.
• Audit package installation for lifecycle-script abuse Review npm workflows for pre-install execution, unexpected postinstall hooks, and scripts that run before code review or scanning can intervene. Block or tightly control lifecycle scripts where business logic does not require them.
• Rotate every credential exposed in the install path Revoke and replace cloud provider keys, GitHub tokens, CI/CD variables, npm publish tokens, and SSH keys that may have been reachable during the compromise window. Treat reuse across systems as a containment failure.
• Hunt for GitHub persistence artifacts Search for rogue self-hosted runners, unfamiliar workflows, suspicious branches, and repository changes tied to stolen tokens. These artifacts can reveal whether the attacker established a continuing GitHub foothold after exfiltration.
• Map leaked secrets back to real identities Correlate each exposed token or key to the cloud role, automation account, or repository authority it can reach. Prioritise the identities whose permissions let a single leaked secret cross environments or assume additional roles.

Key takeaways

• The incident shows how a malicious npm install can become a secrets theft event when build systems still hold reusable machine credentials.
• Its scale was reinforced by more than 25,000 repositories used to store stolen data, which turned exfiltration into a persistence mechanism.
• Security teams need to reduce secret reach into build paths, because rotation alone does not stop reuse when install-time execution has already occurred.

Key terms

• Preinstall Execution: Preinstall execution is code that runs before a package finishes installing. In supply chain attacks, that timing matters because it lets malicious logic execute before many scanners, policy checks, and human reviews can intervene, turning installation into a compromise point rather than a delivery step.
• 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.
• Secret Exfiltration Path: Any route by which sensitive material can leave an environment after it has been read, including shell commands, web requests, diagrams, logs, or rendered outputs. In AI-assisted workflows, the exfiltration path can be created by the assistant itself if output controls are too permissive.
• Supply Chain Persistence: Supply chain persistence is the ability of an attacker to remain active by abusing trusted software distribution paths rather than staying on one host. It often relies on repeated publication, compromised maintainer access, or reusable automation secrets that let the attacker keep reintroducing malicious artifacts.

What's in the full article

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

• Timeline detail on how the malicious npm versions propagated between November 21 and 23, 2025
• Specific examples of the GitHub workflow backdoor and self-hosted runner abuse
• Identity posture guidance for mapping leaked tokens to cloud roles and automation accounts
• Cleanup steps for revoking access keys, npm tokens, and GitHub credentials after exposure

👉 Unosecur's full blog covers the attack chain, GitHub persistence, and identity cleanup steps

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.