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

At a glance

What this is: Shai-Hulud 2.0 is a supply chain campaign that abuses npm installation hooks, CI/CD identities, cloud metadata access, and GitHub workflows to steal secrets and persist inside development pipelines.

Why it matters: It matters because the attack path crosses NHI, cloud, and developer identity boundaries, which means IAM, PAM, and CI/CD governance can no longer be treated as separate control planes.

By the numbers:

• The simulation includes more than 12 new attack scenarios now available in Cymulate Exposure Validation.

👉 Read Cymulate's analysis of Shai-Hulud 2.0 npm supply chain identity theft

Context

npm supply chain security is no longer just a code integrity problem. In this campaign, the package install step becomes an identity event because maintainer accounts, build runners, cloud roles, and repository secrets all become reachable from the same execution path.

For IAM and NHI teams, the critical issue is not only whether a package is trusted, but whether the environment around it can be trusted to resist identity abuse. Once CI/CD systems can read secrets, query cloud metadata, and write back into SCM, the build plane itself becomes an attack surface.

The starting condition is typical for modern software delivery, not an edge case. Many organisations now allow npm installs inside developer endpoints and ephemeral build jobs with broad access to tokens, secrets, and cloud metadata services.

Key questions

Q: What breaks when npm package installs are allowed to execute code before inspection?

A: The control point disappears. If install-time code can run before review, malware can harvest secrets, alter workflows, and propagate before defenders see a stable artifact. That makes preinstall hooks an execution surface, not a packaging detail. Teams should assume installation is a potential compromise event and enforce policy before code reaches that stage.

Q: Why do CI/CD pipelines create non-human identity risk?

A: CI/CD pipelines create non-human identity risk because they authenticate to other systems, carry secrets, and perform privileged actions automatically. When a workflow is compromised, the attacker can inherit that authority and move into cloud, source control, or publishing systems. The pipeline is therefore an identity-bearing control point, not just an execution engine.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: How should teams respond when a package compromise creates workflow persistence?

A: They should isolate the workflow and runner control plane before the attacker can reuse it. That means revoking suspicious tokens, removing unauthorized GitHub Actions files, checking self-hosted runner registrations, and reviewing cloud role usage for evidence of metadata abuse. Containment must include SCM, CI, and cloud identity together.

Technical breakdown

How npm lifecycle hooks become an execution primitive

npm packages can define preinstall and postinstall scripts in package.json, and those scripts run automatically during installation. That means code can execute before a package is fully trusted or even fully laid out on disk. In Shai-Hulud 2.0, that timing matters more than the payload itself. The hook turns routine software installation into an immediate execution path that inherits the permissions of the developer machine or CI runner. Once execution starts that early, normal review gates are often bypassed because the malicious action is already underway.

Practical implication: treat package install as a policy-enforced execution event, not a harmless dependency fetch.

Why CI/CD identities and cloud metadata are exposed together

The campaign targets the overlap between build-system credentials and cloud workload identity. In CI/CD, environment variables, runner tokens, cloud SDK caches, and metadata endpoints can all be reachable from the same process tree. IMDS access is especially dangerous because it can convert a low-privilege container or VM into temporary cloud credentials without a password or interactive login. That makes the build environment a bridge into cloud identity, not just a place where code is compiled. If the runner can query metadata and read secrets, the trust boundary has already failed.

Practical implication: isolate build identities from cloud roles and block unnecessary metadata access from runners.

How workflow injection and repository backdoors persist access

Persistence in this campaign is not just malware staying resident on a host. It also includes malicious GitHub Actions workflows, discussion-body command injection, self-hosted runner registration, and exfiltration through newly created public repositories. Those mechanisms turn SCM into both command-and-control and storage for stolen secrets. The important architectural point is that the attacker does not need repeated interactive compromise once the repository trust model is abused. A compromised token plus workflow write access can create durable, repeatable access inside the software delivery system.

Practical implication: restrict workflow creation, runner registration, and repository write paths to tightly scoped, short-lived identities.

Threat narrative

Attacker objective: The attacker wants repeatable control over development, SCM, and cloud identities so stolen secrets can be exfiltrated, reused, and turned into persistent access.

1. Entry occurs when a developer or CI pipeline installs a trojanised npm package and the preinstall hook runs automatically, creating an immediate foothold inside the build environment.
2. Escalation follows as the payload harvests PATs, repository secrets, cloud credentials, and IMDS-derived tokens, then uses workflow injection and runner registration to widen access.
3. Impact is achieved when the attacker exfiltrates secrets to public repositories, persists through GitHub Actions and self-hosted runners, and gains durable control over CI/CD and cloud identity.

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

Build pipelines are now identity systems, not just delivery systems. Shai-Hulud 2.0 shows that package installation, CI execution, cloud role assumption, and repository write access now sit on the same trust path. That collapses the old separation between code security and identity governance. Practitioners should treat build infrastructure as an identity domain with its own lifecycle, privilege model, and abuse paths.

Low-friction execution at install time creates an identity blast radius that conventional review cycles cannot absorb. The attack succeeds because a package can execute before trust, review, or containment measures fully engage. Once install-time code can access tokens and metadata, the blast radius is determined by what the build plane can already reach. That means entitlement scope, not just malware detection, becomes the critical control variable.

Secret exposure in development environments is a governance failure, not a tooling failure. A token stored in a runner, shell profile, or workflow secret is only as safe as the shortest path from execution to exfiltration. The governing assumption that development access is inherently lower risk no longer holds when runners can reach cloud vaults and SCM controls. The implication is that development identities need the same lifecycle discipline as production identities.

Identity blast radius is the right concept for this threat class. The issue is not one compromised package, but the number of identities and systems reachable from that single execution event. When a maintainer account, a CI token, a cloud role, and a repository secret can all be touched in one chain, the relevant control question is how far one identity can propagate compromise before containment. Practitioners should measure reach, not just compromise volume.

Pipeline persistence now includes governance persistence. By creating workflows, runners, and public exfiltration paths, the attacker embeds itself into the operating model of software delivery. That is why periodic audits are insufficient if they do not revalidate workflow write authority, runner registration, and metadata exposure. Identity governance for SDLC environments must now assume adversarial use of normal automation.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That pattern makes NHI Lifecycle Management Guide relevant because the control problem is not just discovery, but removal, rotation, and offboarding discipline across build identities.

What this signals

Identity blast radius: this is the metric that now matters most for software delivery security. If a single install event can reach secrets, cloud roles, and workflow writes, then the programme question is no longer whether the package is malicious, but how far one compromised execution can travel before containment. Teams should map that reach across CI, SCM, and cloud access paths.

With 27 days to remediate a leaked secret according to The State of Secrets in AppSec, secret exposure in build environments is not a short-lived incident. That lag is long enough for attacker reuse, workflow persistence, and cloud pivoting to become the real operational risk, which is why runtime containment must outrank post-detection cleanup.

Practical programmes should align this threat with OWASP Non-Human Identity Top 10 and the 52 NHI Breaches Analysis, because the same lifecycle failures that expose service accounts also expose build identities. The forward step is to govern CI/CD credentials as non-human identities with explicit lifecycle ownership.

For practitioners

• Inventory install-time execution paths Map every npm preinstall and postinstall script, then require approval or sandboxing for packages that can execute during installation. Prioritise build jobs and developer endpoints that have direct access to secrets, cloud SDK caches, or repository tokens.
• Constrain cloud metadata access from build runners Block unnecessary access to Instance Metadata Service endpoints from CI/CD containers and developer workstations. Where metadata is required, enforce the narrowest possible cloud role and verify that temporary credentials cannot enumerate secrets or assume broader permissions.
• Separate workflow write access from secret read access Use distinct identities for repository maintenance, workflow changes, and secret access so a single compromised token cannot create persistence and exfiltration together. Review self-hosted runner registration and GitHub Actions write permissions as high-risk control points.
• Add detection for secret harvesting behaviors Look for unexpected TruffleHog execution, bulk environment variable collection, base64-encoded log output, new public repository creation, and abnormal workflow files appearing under .github/workflows. These signals often precede wider secret reuse.

Key takeaways

• Shai-Hulud 2.0 turns npm installation into an identity compromise path that reaches maintainer accounts, cloud roles, and repository secrets.
• The attack demonstrates that build systems can become persistent access infrastructure when workflow permissions, metadata access, and runner registration are not tightly governed.
• Practitioners should reduce identity blast radius in CI/CD by constraining install-time execution, isolating metadata access, and separating workflow control from secret access.

Key terms

• 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.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Workspace Persistence: A condition where an AI agent leaves behind files or settings that continue to influence execution after the session ends. In agentic environments, this is dangerous because the hostile action may occur later through trusted host components, not through the agent itself.
• Build identity: The set of credentials, tokens, keys, and permissions used by CI/CD systems, runners, and developer tooling. Build identity is often overlooked, yet it can expose secrets, alter repositories, and propagate compromise into downstream software if not tightly scoped and monitored.

What's in the full article

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

• Step-by-step simulation flows for the preinstall hook, workflow injection, and IMDS credential theft paths.
• Scenario-level output examples showing how the payload behaves in developer machines, CI runners, and cloud instances.
• Detection engineering content including EDR rules, Sigma detections, and mitigation text for build and SCM abuse.
• More than 12 attack scenarios in Cymulate Exposure Validation for testing the attack chain end to end.

👉 Cymulate's full post covers the attack chain, simulation paths, and detection engineering examples.

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.