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 consequences, with the key finding that compromised packages turned routine installs into large-scale credential theft and persistence.

Why it matters: It matters because CI/CD secrets, cloud tokens, and service credentials are NHI assets, and one poisoned dependency can expose the access paths that IAM teams are still struggling to govern.

By the numbers:

• Malicious packages released between November 21 and 23, 2025 triggered pre-install execution before the package was even installed.

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

Context

npm supply chain compromise becomes an IAM problem the moment a package can execute code during installation and read tokens already present on a developer laptop or CI runner. In that model, the package is only the delivery mechanism; the real security issue is that non-human identities, secrets, and automation credentials are reachable before any runtime policy has a chance to intervene. For the broader NHI governance discussion, this is a familiar failure pattern rather than an isolated malware story.

The article is strongest when read as a warning about identity blast radius. Once cloud keys, GitHub tokens, and pipeline secrets are harvested, the attacker can reuse them across repositories and environments with little friction. That makes this incident typical of modern supply chain abuse: the compromise begins in software distribution, but the durable risk sits in credential sprawl, privilege spread, and weak revocation discipline.

Key questions

Q: How should security teams respond to an npm supply chain attack that exposes cloud credentials?

A: Treat it as an identity incident, not only a software incident. Remove the malicious packages, rotate every exposed credential, and review build logs, workflow changes, and runner registrations for persistence. Then map each stolen secret to the identity it represents so you can close every reachable path instead of only the obvious one.

Q: Why do npm supply chain attacks create such a large blast radius?

A: Because install-time code can inherit access from developer laptops and CI runners, which often already hold cloud tokens, GitHub credentials, and automation secrets. One malicious dependency can therefore expose many non-human identities at once, and each identity may unlock more accounts, repositories, or secret stores.

Q: What is the difference between secrets rotation and identity posture cleanup after a compromise?

A: Secrets rotation replaces the exposed credentials, while identity posture cleanup removes the excess permissions, stale runners, hidden workflows, and overbroad role paths that made the compromise useful. Rotation limits immediate reuse, but posture cleanup reduces the attacker’s ability to pivot or persist after revocation.

Q: When should teams treat a package compromise as a cloud security event?

A: As soon as the package can execute in a context that holds secrets, metadata tokens, or publishing rights. At that point the issue is no longer just code integrity. It is the exposure of non-human identities that can be reused across cloud, source control, and CI/CD systems.

Technical breakdown

Pre-install scripts turn dependency installs into execution events

In npm, lifecycle scripts can run before a package is fully installed, which means a malicious dependency can execute code as soon as a developer or CI job runs npm install. That shifts the trust boundary from verified package content to local execution on the build host. If the host already has cloud tokens, metadata credentials, or automation secrets, the payload can read them immediately. The key technical problem is not just package integrity. It is that install-time execution often inherits the same access as the surrounding developer or runner context.

Practical implication: Disable unnecessary lifecycle scripts in build environments and treat install-time code execution as a privileged event.

Credential harvesting in CI/CD exposes non-human identities at scale

The malware scraped environment variables, metadata tokens, cloud configuration files, SSH keys, GitHub tokens, npm publish tokens, and CI/CD secrets. That is a broad NHI harvesting pattern because it targets identities rather than data alone. When secrets are present in automation, the attacker can reuse them to assume roles, access secret stores, or publish new malicious packages. This creates a feedback loop: one stolen identity reveals more identities, and each one may carry different privilege scope, TTL, and revocation complexity.

Practical implication: Map every credential class to the identity it represents so revocation and containment can be executed without guesswork.

Persistence is easier when attackers can turn identity into infrastructure

The campaign did not stop at exfiltration. It registered infected machines as self-hosted runners, added workflows tied to GitHub events, and used stolen tokens to republish altered packages. That matters because persistence moved from a single endpoint to the software delivery plane itself. In practice, this is a hybrid identity issue: access spans source control, package registries, cloud platforms, and CI orchestration. Once those identities are linked, a compromise in one place becomes a standing foothold elsewhere.

Practical implication: Review runner registration, workflow permissions, and package publishing rights as part of the same identity control surface.

Threat narrative

Attacker objective: The objective was durable access to cloud and software supply chain identities that could be reused for exfiltration, persistence, and lateral movement across environments.

1. Entry occurred when attackers published malicious npm package versions that executed during pre-install on developer laptops and CI/CD runners.
2. Escalation followed as the malware harvested cloud credentials, GitHub tokens, and pipeline secrets from environment variables, config files, and metadata services.
3. Impact came from repository creation, workflow backdoors, and republishing infected packages, which allowed persistence and cross-victim credential reuse.

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

Identity blast radius is now the decisive control variable in software supply chain compromise. The malware only needed one execution opportunity, but the damage depended on how many identities were reachable from that host. That is the NHI governance lesson: secret sprawl, overprivilege, and weak revocation convert a package compromise into an enterprise access event. Practitioners should treat every build node as a potential identity junction, not just a deployment endpoint.

Ephemeral credentials do not eliminate trust debt when the surrounding identity model is still broad and sticky. Temporary tokens reduce dwell time, but they do not help if runners, developer machines, and service accounts can still chain into broader permissions. The better framing is whether the organisation can bound what one compromised identity can touch. IAM teams should measure privilege adjacency, not only token lifetime.

Supply chain defence now requires identity telemetry, not just dependency hygiene. Package pinning, lockfiles, and script restrictions help, but they do not answer the operational question of which identities were exposed, assumed, or repurposed after compromise. The field needs a tighter link between software provenance and cloud identity posture. Practitioners should align build security with continuous identity monitoring and revocation workflows.

Shai-Hulud-style attacks validate the OWASP NHI Top 10 concern about secret exposure and overprivilege. The attack chain moved cleanly from package execution to credential theft to persistence, which is exactly why NHI governance cannot stay isolated from DevOps controls. The practical conclusion is that software delivery teams and identity teams need one shared incident model for secrets, runners, and workload access.

Runtime detection alone will not solve a problem that begins with trust in the wrong place. By the time exfiltration is visible, the attacker may already have republished packages or planted workflows. That means the control objective should shift left into provisioning, scope reduction, and rapid revocation. Teams that cannot answer where their credentials live will struggle to answer where their compromise ended.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Our research also found that AI-related credential leaks surged 81.5% year over year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a related control view, read OWASP NHI Top 10 for the risks that emerge when autonomous systems inherit secrets and tool access.

What this signals

Ephemeral credentials help, but they do not solve identity adjacency. If build systems, runners, and developer workstations can still reach broad roles or publish permissions, the attack surface remains large even when tokens expire quickly. Teams should pair short-lived access with tighter scope, explicit runner trust, and continuous revocation validation. That is the difference between reducing dwell time and reducing blast radius.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the pattern is clear: new tooling layers create new secret surfaces before governance catches up. The lesson for practitioners is to inventory access paths by workflow, not by platform, because the same secret often exists in multiple places at once.

Identity adjacency is the hidden control gap. The practical question is not just whether a secret was leaked, but what that secret can reach after the first hop. Security programmes should prioritize telemetry that connects source control, CI/CD, cloud IAM, and secret stores, then use that graph to drive revocation, privilege reduction, and runner trust decisions.

For practitioners

• Harden npm execution paths Disable unnecessary lifecycle scripts in CI/CD and on developer endpoints, then pin dependencies and clear stale caches before reinstalling trusted versions.
• Rotate every exposed identity Revoke and replace cloud provider keys, GitHub tokens, npm tokens, SSH keys, and pipeline credentials that could have been read from environment files or metadata services.
• Audit GitHub for persistence artifacts Look for unfamiliar workflows, unapproved self-hosted runners, new branches, and references to Shai Hulud, then validate that no attacker-owned automation remains.
• Map identities to privilege scope Build a relationship view that ties each leaked secret to the role, repository, runner, or cloud account it can reach so revocation can be complete and prioritized.
• Unify build and identity telemetry Correlate dependency install events, token usage, role assumption, and secret-store access so a package compromise can be traced through the identity layer quickly.

Key takeaways

• A package install can become a cloud identity compromise when lifecycle scripts execute with access to secrets and automation credentials.
• The incident scale is driven by credential reuse, privilege spread, and persistence mechanisms that outlive the original package compromise.
• Teams need one response model for dependency hygiene, secret rotation, and identity posture cleanup if they want to reduce repeat exposure.

Key terms

• Non-Human Identity: A non-human identity is any machine- or software-based credential used to authenticate and authorize actions, including service accounts, API keys, tokens, certificates, bots, and AI agents. In practice, it is the access layer that lets automation act, and it must be governed with the same discipline as human identity.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, pipelines, chat tools, ticketing systems, and endpoints. It increases the chance that one leak becomes many breaches because the same credential often exists in multiple places, each with different revocation and ownership challenges.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can do after compromising a single credential or account. It is shaped by privilege scope, role chaining, token lifetime, and persistence paths, so reducing it means limiting what any one identity can reach, not only how often it rotates.
• Supply Chain Execution Risk: Supply chain execution risk is the danger that trusted software or build dependencies can run code in environments that already hold sensitive access. In npm and CI/CD contexts, the risk is not only malicious packages but also the secrets and privileges available at install time.

What's in the full article

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

• Step-by-step cleanup actions for npm caches, node modules, and compromised package versions.
• Detailed identity visibility workflow for mapping leaked secrets to specific cloud and GitHub accounts.
• Examples of suspicious GitHub artifacts, including self-hosted runners and workflow persistence markers.
• Operational guidance on reducing blast radius with short-lived scoped credentials and privilege remediation.

👉 Unosecur's full post covers the attack chain, exposed credentials, and identity remediation actions.

Deepen your knowledge

Shai-Hulud-style supply chain exposure and cloud identity blast radius are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme from a similar starting point, it is worth exploring.