Shai Hulud 2.0 turns npm installs into NHI secret exposure

At a glance

What this is: A Shai Hulud-style npm campaign is using install-time execution to exfiltrate developer and CI/CD secrets from compromised packages into attacker-controlled GitHub repositories.

Why it matters: It matters because npm supply chain compromise now directly maps to NHI governance, where secrets placement, token scope, and revocation speed determine how far an attacker can move.

By the numbers:

• The top 5% of affected repositories were responsible for 57.0% of all exposed credentials.
• Entro Security classified 79.9% of the leaked material as SaaS and productivity tokens, showing that the campaign primarily targets reusable non-human access rather than application code.

Context

Shai Hulud 2.0 is a supply chain attack pattern in which a malicious npm package executes during installation and uses that trust boundary to collect secrets from developer machines and CI/CD workers. The important governance issue is not only package integrity, but the identity material already present in the environment when install-time code runs.

In this case, the campaign targets non-human identity assets such as GitHub PATs, cloud credentials, CI/CD tokens, API keys, and short-lived metadata-based credentials. That makes the attack an NHI governance problem as much as a software supply chain problem, because the attacker is stealing the permissions attached to the build and developer estate rather than merely corrupting the package itself.

The article also notes activity around agent-related integrations, but the central pattern remains broader: install-time compromise converts ordinary build and developer workflows into secret collection points. That is a typical exposure pattern for modern software supply chains, even if the scale in this campaign is unusually high.

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 stolen developer tokens and standing access make software supply-chain attacks so hard to contain?

A: Stolen maintainer tokens turn a single compromise into a distribution problem. Attackers can publish malicious package versions, republish through trusted ecosystems, and move laterally into cloud, CI, and secrets stores. Standing access increases the blast radius because the attacker can act quickly before defenders detect the abuse and revoke credentials.

Q: How do security teams spot NHI secret exposure before it becomes a wider incident?

A: Look for unexpected secret-scanning activity, abnormal repository creation, environment dumps, and installs that generate local credential artifacts. Those signals indicate the environment is being mined for tokens rather than merely executing software. The practical goal is to detect credential harvesting as early as possible in the build and developer pipeline.

Q: How should teams respond when a package ecosystem starts showing repeated credential theft?

A: They should assume the attacker is pursuing propagation, not a one-off compromise. Prioritise revocation of exposed credentials, review workflow and publishing permissions, and inspect repository mutation history for signs of cross-ecosystem spread. The fastest containment comes from cutting identity reuse paths before the malware can recurse into new environments.

Technical breakdown

Install-time execution turns trusted package installs into secret harvesters

npm lifecycle scripts run before or during package installation, which means attacker code can execute inside developer workstations and CI pipelines without waiting for application runtime. That matters because install contexts often have access to environment variables, cached credentials, cloud metadata endpoints, package publishing tokens, and SCM authentication material. A malicious package does not need to exploit the app logic if the environment already exposes the secrets the package can read. The technical risk is therefore a trust shift: the package manager becomes the execution channel, and the build environment becomes the loot source.

Practical implication: treat npm install as a privileged execution point, not a harmless dependency fetch.

Why secret scanners and local artifacts increase the blast radius

The campaign uses secret scanning tools and writes collected material into local files before exfiltration, which makes the attack scalable and noisy in a way defenders can detect, but also efficient for the attacker. Artifacts such as environment dumps and scan outputs create a structured inventory of credentials across cloud, SCM, SaaS, and CI/CD systems. Because many organisations still store secrets in code, config files, and pipeline assets, a single compromise can surface a large and varied credential set. The technical issue is not one secret type, but the aggregation of many secret classes into a reusable theft bundle.

Practical implication: monitor for secret-scanning tools, unexpected artifact creation, and unusual repo pushes from install-time processes.

Token reuse connects package compromise to lateral movement

Once the attacker has reusable tokens, the incident stops being a simple leak and becomes a propagation mechanism. GitHub tokens, package publishing rights, and CI credentials can be chained to publish malicious versions, expose private repositories, or seed additional install events that repeat the theft cycle. In NHI terms, this is standing privilege abuse: credentials remain valid long enough to be reused across systems, and the attacker uses that reuse to widen access. The result is a supply chain worm effect in which every additional token can become a new launch point.

Practical implication: prioritise rapid revocation and scope reduction for tokens that can publish, deploy, or read private sources.

Threat narrative

Attacker objective: The attacker wants to harvest reusable non-human credentials at scale and turn them into broader ecosystem compromise through repeated package poisoning.

1. Entry occurs when a maintainer account or package publishing path is abused to ship a malicious npm version that runs during install.
2. Credential access follows as the payload reads environment variables, queries cloud metadata endpoints, and scans for tokens, keys, and PATs on developer and CI systems.
3. Escalation and lateral movement occur when the stolen tokens are reused to publish more packages, expose repositories, and trigger additional installs across the ecosystem.
4. Impact is the large-scale exposure of NHI secrets that can be replayed into cloud, SCM, CI/CD, and SaaS environments.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• 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).

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Install-time package execution is now an identity control point: The campaign shows that dependency trust alone is not enough if the installer can read the same secrets that production services use. npm lifecycle hooks run inside environments rich in NHI material, so the real governance question is what identity objects exist at install time, not just what code was fetched. Practitioners should treat package installation as a credential exposure boundary, not a software-only event.

Secret placement debt is the hidden accelerator: The campaign only becomes this damaging when secrets already live in developer endpoints, build jobs, logs, and artifacts. That is not a package problem by itself, it is a lifecycle failure in NHI governance. The implication is that secrets sprawl, not package malware, is what allows a single malicious install to become a broad compromise.

Standing privilege multiplies the effect of a compromised package: Long-lived GitHub tokens, cloud keys, and CI/CD credentials remain reusable after the initial theft, which gives the attacker a propagation path across publishing, source control, and deployment workflows. This is an example of identity blast radius, where one exposed credential family can expand into multiple control planes. Practitioners need to understand that the damage comes from reuse authority, not just from initial exposure.

Shai Hulud 2.0 proves the NHI attack surface extends into software supply chains: A package compromise becomes an identity event once the payload steals tokens, keys, and automation credentials instead of modifying application behaviour. That broadens the governance remit for OWASP-NHI, CI/CD security, and secrets management into one control problem. The practitioner conclusion is that supply chain governance must include the identities already embedded in the pipeline.

Attackers now exploit trust chains between maintainer accounts, packages, and automation identities: The article’s pattern is not only package tampering, but delegation abuse across human maintainer rights, machine tokens, and pipeline credentials. That means the governance model has to follow the delegation chain, because compromise at one hop can activate permissions at the next. The field should stop treating source control, build systems, and NHI governance as separate disciplines.

From our research library:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secret exposure debt: The campaign succeeds because secrets already sit in places that install-time code can read, especially code, config files, and CI/CD tools. 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. Practitioners should treat this as a governance failure, not just a malware event.

Supply chain trust now includes identity exposure: Once a package install can harvest tokens, the attacker has moved from software compromise to identity compromise. Security teams should assume that any build path exposing developer or CI credentials can be converted into a propagation point if install-time execution is not tightly controlled.

For practitioners

• Harden npm install-time execution Restrict lifecycle script execution in developer and CI/CD contexts where possible, and inventory which build paths still allow preinstall or install hooks to run with privileged environment access.
• Remove secrets from build-adjacent locations Move credentials out of code, config files, CI variables, and artifact stores so a compromised dependency cannot harvest a ready-made credential cache.
• Shorten token blast radius Replace reusable tokens with narrower-scoped credentials, reduce standing privileges, and invalidate any NHI credential that could publish packages or touch private repositories.
• Instrument for secret theft patterns Alert on unexpected secret-scanning tools, mass file creation such as environment dumps, and outbound repository activity from install-time processes or CI workers.
• Tighten third-party package governance Review which npm packages can reach production build paths, and require ownership and maintainer verification for dependencies with access to high-value secrets.

Key takeaways

• The core failure is not only malicious package code, but the presence of reusable NHI secrets in environments that npm install can reach.
• Entro Security reports 26,000-plus affected repositories and 8,425,892 secret findings, showing how quickly install-time theft scales.
• The limiting control is credential placement and reuse discipline, because a stolen token can spread compromise far beyond the first package.

Key terms

• 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.
• Secret Exposure Pipeline: A workflow that turns one compromised system into a stream of leaked credentials by collecting secrets, storing them in artifacts or repositories, and pushing them into attacker-controlled destinations. The phrase describes a propagation pattern where theft is automated through normal development tooling.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Credential Reuse: Credential reuse happens when the same password, token, or secret can unlock multiple systems or sessions. It increases breach impact because one stolen credential can become a wide-ranging access path. The control problem is not only theft, but the amount of trust packed into each reusable secret.

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.