Shai Hulud 2.0 turns npm installs into NHI secret exposure

TL;DR: A new Shai Hulud-style supply chain campaign is abusing npm install time to harvest developer and CI/CD secrets, with researchers reporting more than 26,000 affected repositories and 8.4 million exposed secret findings, according to Entro Security research. The pattern shows that supply chain compromise now lands directly on NHI governance, where token scope, rotation, and revocation determine blast radius far more than package trust alone.

At a glance

What this is: Shai Hulud 2.0 is a supply chain campaign that turns npm installs into a secret-exfiltration pipeline against developer and CI/CD environments.

Why it matters: For IAM and NHI practitioners, it shows that package trust failures rapidly become identity governance failures when long-lived tokens, cloud keys, and automation credentials are present.

By the numbers:

• 5% of affected repositories were responsible for 57.0%
• The malware captured roughly 1.4% cloud access keys and IAM roles, 15.6% Git hosting personal access tokens, and 79.9% SaaS and productivity tokens.

👉 Read Entro Security's analysis of Shai Hulud 2.0 and NHI secret exposure

Context

Shai Hulud 2.0 is a supply chain attack that abuses trusted npm package updates to execute during installation, harvest secrets, and exfiltrate them into attacker-controlled GitHub repositories. The primary NHI governance problem is not the package itself but the access material sitting on developer machines and CI/CD workers when npm install runs.

This matters because the attack path converts ordinary build activity into a credential collection event. When ephemeral jobs, long-lived tokens, and cloud metadata access all coexist in the same pipeline, a single compromised dependency can expose the wider identity layer rather than one application.

The article’s starting position is typical of modern software supply chain exposure: the package is only the delivery mechanism, while the secrets are the real target.

Key questions

Q: How should security teams reduce the risk of secret theft from npm supply chain attacks?

A: Security teams should assume install-time code can read any credential present in the build environment. The safest approach is to keep installs away from production secrets, use ephemeral runners, and enforce least privilege on every token. Secret detection matters, but automated revocation and scoped access reduce the real blast radius.

Q: Why do npm supply chain attacks often become NHI governance failures?

A: Because the attacker usually wants the credentials, not the application code. Developer workstations and CI systems often hold GitHub tokens, cloud keys, SaaS tokens, and automation secrets that act as non-human identities. Once those are stolen, the incident becomes a lifecycle, scope, and revocation problem, not only a code integrity issue.

Q: What is the difference between secret exposure and NHI compromise?

A: Secret exposure is the discovery or leak of a credential. NHI compromise happens when that credential still grants working access and can be used to act as a machine, service, or agent. Exposure is the event. Compromise is the operational outcome, and it depends on scope, validity, and revocation speed.

Q: When should teams prioritise CI/CD hardening over broader secret scanning?

A: Prioritise CI/CD hardening when pipelines can reach privileged credentials or deploy to production, because those environments often turn one leaked secret into many. Secret scanning still matters, but pipeline isolation, minimal token scope, and short-lived access reduce the number of credentials available to steal in the first place.

Technical breakdown

Why preinstall hooks are so effective in npm supply chain attacks

npm lifecycle scripts can execute before an application is fully installed, which means a malicious package can run in the preinstall phase as soon as a developer or CI job fetches dependencies. That makes the install step itself a privileged execution point. The attacker does not need runtime code execution inside the target application. They only need access to the environment where secrets are already present, such as shell variables, local config files, cloud metadata endpoints, and build logs. In practice, this collapses the line between dependency management and credential exposure.

Practical implication: Treat dependency install as an execution boundary and restrict the secrets available to any environment that runs npm install.

How secret harvesters turn developer machines into NHI collection points

The campaign is effective because it searches for many secret classes at once: GitHub tokens, cloud credentials, CI/CD secrets, SaaS tokens, and API keys. These are all non-human identities in operational form, because they grant machines or automations reusable authority. Once harvested, they can be written into local artifacts and then pushed to attacker-controlled repositories for later reuse. That creates a durable access layer even when the original package compromise is discovered, because the credentials may remain valid until revoked. Detection without revocation leaves the attacker with a working identity.

Practical implication: Map every exposed secret to its owning workload or automation account so revocation can happen immediately and by identity type.

Why token reuse creates supply chain blast radius

When stolen tokens still work, the attacker can move from theft to propagation. A package maintainer token, GitHub personal access token, or CI credential can be used to publish altered packages, alter workflows, or expose more repositories. That is why supply chain compromise and NHI compromise reinforce each other. The attacker is not simply stealing secrets from one environment. They are trying to reuse those secrets as a distribution mechanism. This is the same basic failure mode seen in broader NHI breaches: one credential becomes a bridge into many systems when scope and rotation are weak.

Practical implication: Shorten token lifetimes, narrow permissions, and remove any ability for one stolen credential to publish or redeploy at scale.

Threat narrative

Attacker objective: The attacker wants reusable non-human identities that can be used to expand supply chain access, expose more repositories, and preserve durable access through valid tokens.

1. Entry via compromised npm packages that execute during the preinstall phase on developer machines and CI/CD workers.
2. Credential harvest from environment variables, cloud metadata endpoints, and local scanning of secret material.
3. Escalation and propagation through reuse of GitHub, cloud, and automation tokens to seed additional attacker-controlled repositories.

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

Supply chain compromise is now an identity governance problem, not just a software provenance problem. The key failure is not only that a package was compromised. It is that build and developer environments already contained tokens, keys, and automation credentials that could be stolen at scale. That makes the control plane for NHI governance the build system itself. Practitioners should treat package trust, secret sprawl, and access scope as one operating problem.

Ephemeral credential trust debt is the new blast-radius multiplier. The campaign shows that temporary credentials are safer only when they are tightly scoped and quickly revoked. If ephemeral access is copied into logs, artifacts, or surrounding automation, it becomes durable again. That means the governance question is not whether a token expires, but whether it can be reused before the attacker cashes it in. Teams should design for immediate unusability after compromise.

Install-time execution should be treated as a high-risk privilege boundary. Package installation is often considered routine, yet in this pattern it becomes code execution with access to the richest secrets in the environment. That changes how security teams should view dependency controls, CI isolation, and developer workstation hygiene. The practical conclusion is simple: if install can read secrets, then install needs the same guardrails as other privileged paths.

NHI blast radius now depends on how many systems share the same secret class. The article shows one campaign capturing cloud keys, Git hosting tokens, CI/CD credentials, SaaS tokens, and AI-related secrets in a single sweep. That breadth matters because it collapses multiple governance domains into one incident. A mature NHI programme should classify by identity purpose, not by storage location, so a compromise in one layer does not silently spill into five others.

AI and agent credentials belong in the same governance model as human-access tokens. The leak set included AI-related credentials alongside mainstream cloud and SaaS secrets, which shows that agentic environments are already part of the attack surface. As agents become more common, their secrets will be harvested by the same tooling that targets developer and automation identities. Practitioners should extend lifecycle controls, revocation workflows, and monitoring to every machine-issued credential.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• 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 broader view of how these failures recur across environments, read The 52 NHI breaches Report for root cause patterns and repeat control breakdowns.

What this signals

Shai Hulud-style attacks compress the gap between software supply chain risk and identity risk. The programme implication is that teams can no longer isolate dependency control from secret lifecycle control. If a build system can read reusable credentials, then a package compromise becomes an access compromise almost immediately. That makes secret placement, runner isolation, and revocation automation first-order governance issues, not cleanup tasks.

Ephemeral credentials do not eliminate exposure if they are reachable from routine developer workflows. Temporary access still needs strict boundaries, because install-time malware can collect and reuse it before expiry. The governance lesson is that token lifetime is only one variable; scope, environment exposure, and artifact leakage matter just as much. Teams should tighten all four together.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per The State of Secrets Sprawl 2026, agent and tool integrations are already part of the secret sprawl problem. As organisations expand AI and automation, the same leakage patterns will follow them into new control planes unless identity ownership is explicit. That is the point where NHI governance must move from ad hoc cleanup to continuous lifecycle management.

For practitioners

• Isolate dependency installs from production secrets Run npm install in environments that do not contain long-lived cloud, Git hosting, or SaaS credentials. Use ephemeral build workers with minimal access, and separate dependency fetching from any step that can reach privileged identities.
• Inventory every NHI secret exposed to developer workflows Map GitHub tokens, cloud keys, CI/CD tokens, and AI service credentials to a named owner, purpose, and rotation path. This lets responders revoke by identity class instead of searching manually after exposure.
• Enforce immediate revocation on secret exposure Automate revocation when leaked credentials are detected in logs, repositories, or build artifacts. Detection alone is insufficient when 64% of valid leaked secrets can remain exploitable later, and stale tokens extend attacker dwell time.
• Review package publishing and workflow permissions Limit who can publish npm packages and who can modify GitHub workflows or release automation. A stolen maintainer token should not be enough to spread malicious versions or flip additional repositories into attacker control.
• Use NHI breach pattern analysis to guide controls Study the 52 NHI breaches Report alongside this campaign to identify repeat failure modes in token reuse, poor scope design, and delayed revocation across non-human identities.

Key takeaways

• Supply chain malware becomes a credential incident as soon as build environments hold reusable secrets.
• The scale of exposed credentials shows why detection alone cannot contain NHI risk without fast revocation.
• Teams should harden install paths, scope tokens tightly, and manage every machine credential as a governed identity.

Key terms

• Non-Human Identity: A non-human identity is any machine, workload, service, bot, token, certificate, or agent that authenticates and acts inside an environment. In practice, these identities carry permissions, lifecycles, and revocation needs just like human accounts, which makes them a core governance object.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, pipelines, logs, workstations, and collaboration tools. It creates hidden access paths that are hard to inventory and harder to revoke, especially when the same secret is duplicated across multiple systems and environments.
• 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.
• Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.

What's in the full article

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

• The repository-level breakdown of leaked secret types, including which credential classes dominated the affected dataset
• The detector and scanning workflow used to classify exposures across more than 26,000 linked repositories
• The public checker workflow for searching by repo owner, email address, or secret hash
• The campaign timeline and ecosystem examples tied to compromised npm packages and GitHub exfiltration

👉 The full Entro Security post includes repository counts, secret class breakdowns, and the exposure checker details

Deepen your knowledge

Shai Hulud-style secret exposure and NHI lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building controls for developer and CI/CD identities, it is worth exploring.