Shai Hulud 2.0 turned CI environments into NHI compromise paths

TL;DR: Shai Hulud 2.0 affected 1,195 organizations and left valid cloud and CI credentials usable more than 72 hours after disclosure, according to Entro researchers who analysed over 30,000 attacker-controlled repositories. The incident shows that CI pipelines, developer endpoints, and cloud runners now behave like NHI compromise surfaces, not just code storage.

At a glance

What this is: Shai Hulud 2.0 was a supply chain campaign that exposed how CI runners, developer endpoints, and cloud machines can become NHI compromise surfaces rather than just repository incidents.

Why it matters: For IAM and NHI practitioners, the key lesson is that secret leakage in build and runtime environments can persist beyond disclosure unless identities, tokens, and runner access are governed together.

By the numbers:

• 1, ntro researchers tied exfiltrated data to 1,195 organizations across banks, governments, healthcare, and Fortune 500 tech.
• Valid cloud and CI credentials were still observed more than 72 hours after public disclosure.

👉 Read Entro's analysis of Shai Hulud 2.0 and compromised NHI environments

Context

Shai Hulud 2.0 is a useful example of why non-human identity governance cannot stop at repository scanning. The primary risk sits in the places where code executes, because CI runners, developer endpoints, and cloud-connected machines often hold live secrets that can be reused immediately if they are exposed.

Entro's analysis shifts the focus from attacker-controlled repositories to runtime environments, where memory snapshots, local configuration, and active credentials were harvested. That framing is closer to the reality practitioners face: a compromise in the build path can become an identity compromise across systems, teams, and cloud estates.

The organisations named in the report are not an unusual edge case. They are a representative warning that the current NHI control model still leaves execution environments under-governed.

Key questions

Q: How should security teams reduce risk from secrets in CI environments?

A: They should minimise the number of long-lived credentials available to build jobs, use short-lived scoped tokens where possible, and treat runners as privileged systems. Every pipeline should have a clear revocation path so that exposed secrets can be invalidated quickly when compromise is suspected.

Q: Why are runtime environments riskier than repository scans for NHI governance?

A: Because runtime environments can expose secrets that never touch a repository. Memory dumps, environment variables, and local configuration can reveal live credentials during execution, which means repository scanning alone will miss the most dangerous exposures.

Q: What is the difference between secrets exposure and credential reuse risk?

A: Secrets exposure is the moment a token, key, or certificate becomes visible to an attacker. Credential reuse risk is the period during which that secret remains valid and trusted. The second is what creates real blast radius, because a leaked secret only becomes an active compromise if it still works.

Q: When should organisations rotate credentials after a supply chain incident?

A: They should rotate immediately when there is a credible chance that build, endpoint, or cloud execution paths were exposed. Rotation should not wait for perfect attribution, because modern supply chain attacks can harvest secrets fast and use them before teams finish investigation.

Technical breakdown

Why CI runners are high-value NHI targets

CI runners are transient execution environments, but they often inherit broad access to source control, cloud APIs, package registries, and chat or ticketing systems. That makes them ideal collection points for malware that executes during dependency installation or build steps. In this case, the payload harvested runtime context and memory-resident values, which is more dangerous than stealing a single static secret file. The technical failure is not just secret storage. It is the assumption that short-lived infrastructure is low risk when it actually concentrates privileged tokens, service account material, and automation trust.

Practical implication: Practical implication: treat runners as privileged NHI workloads and limit what they can reach.

How memory dumping changes the secrets problem

Traditional secrets controls focus on files, environment variables, and repository hygiene, but memory dumping bypasses those boundaries. If a malicious dependency executes during install or test phases, it can read process memory, scrape environment state, and capture ephemeral tokens before defenders ever see a committed secret. That means scanner coverage alone is insufficient. The architecture problem is that secrets used during execution are often more exposed than secrets stored at rest, especially when they are reusable across cloud, SaaS, and CI platforms. Governance must therefore cover runtime exposure, not just secret creation and storage.

Practical implication: Practical implication: add runtime containment and revocation triggers, not just pre-commit detection.

Why valid credentials remain the real blast radius

A leaked credential becomes a live access path only if it is still valid, still scoped broadly enough to matter, and still trusted by connected systems. In the report, some credentials remained usable days after disclosure, which shows that detection without revocation leaves the attacker with a usable window. For NHI governance, the problem is lifecycle latency: discovery, validation, ownership, and rotation are too slow relative to modern supply chain compromise timelines. The technical control objective is to reduce the usable life of every secret and every automation identity.

Practical implication: Practical implication: shorten credential lifetime and automate revocation across the full NHI lifecycle.

Threat narrative

Attacker objective: The attacker aimed to harvest usable non-human credentials from execution environments and turn them into broader access across cloud and SaaS systems.

1. Entry occurred through a compromised npm dependency that executed during the preinstall phase of a build job.
2. Credential harvesting followed as the payload collected environment variables, memory snapshots, and local configuration from CI runners and developer endpoints.
3. Impact came from the reuse of still-valid cloud, CI, and collaboration credentials that could be applied against live systems days after disclosure.

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

Shai Hulud 2.0 is not primarily a repository story, it is an identity lifecycle story. The attacker-controlled repos were a collection layer, not the core asset at risk. The real exposure sat in CI runners, developer machines, and cloud-connected environments where live NHI secrets could be harvested and reused. That distinction matters because governance built around source control alone will miss the most dangerous part of the attack path. Practitioners should treat execution environments as first-class identity surfaces.

Ephemeral infrastructure creates ephemeral trust debt: short-lived systems still accumulate long-lived access. Build jobs, package install hooks, and automation tasks often inherit more privilege than teams realise, then outlive the assumptions that made them acceptable. Once secrets are harvested from memory or runtime context, the control problem becomes one of revocation speed and ownership clarity. Organisations need policies that assume every execution path may leak credentials and must be closed quickly.

Runtime compromise has become a standard NHI failure mode, not an edge case. When malware can extract tokens from memory and local config, the old boundary between endpoint security, DevSecOps, and IAM breaks down. Security programmes that keep these domains separate will continue to undercount blast radius. The practical conclusion is to unify build security, secrets management, and NHI governance under one operating model.

Identity blast radius: the usable damage from one exposed credential is determined by its scope, lifetime, and downstream trust relationships. This incident shows that blast radius is often larger than the initial leak because multiple systems still accept the same token or service account. Teams should measure not just how many secrets are exposed, but how far each one can move once stolen. The right control target is reduced trust radius, not just fewer findings.

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.
• See also The State of Secrets in AppSec for the 43% developer best-practices gap that keeps leakage recurring.

What this signals

Secret sprawl is now an execution-environment problem, not only a code hygiene problem. The pattern in Shai Hulud 2.0 suggests that teams need to govern where secrets are used, not just where they are stored. With 64% of valid secrets leaked in 2022 still valid and exploitable today, according to The State of Secrets Sprawl 2026, the remediation gap is now a governance signal in its own right.

That shifts programme priorities toward revocation speed, runner segmentation, and ownership mapping across CI, cloud, and SaaS. If teams cannot answer which identity owns a credential and where it can still be used, they cannot claim meaningful control over NHI exposure.

Ephemeral credential trust debt: the hidden risk created when short-lived systems inherit long-lived privileges and those privileges are not closed out promptly. This is the control gap that will keep recurring as more software runs with autonomous access and shared automation tokens.

For practitioners

• Restrict secrets in build and test environments Remove broad cloud, SaaS, and collaboration tokens from CI jobs wherever possible, and replace them with narrowly scoped, short-lived credentials. Keep runner permissions minimal and separate release automation from general build activity.
• Add runtime revocation workflows for exposed credentials When a pipeline compromise is suspected, trigger immediate validation, rotation, and owner notification for every secret used by that workflow. The goal is to compress the window between exposure and invalidation, especially for cloud and service account keys.
• Classify CI runners as privileged NHI workloads Inventory runners, endpoint automation, and build agents as managed identities with owners, scopes, and review cadences. Apply the same control expectations you would use for other high-value non-human identities, including access review and usage monitoring.
• Monitor for package-install execution paths Inspect dependency install and preinstall behaviour in pipelines, because that is where malicious code can execute before normal application controls are in place. Combine this with artifact hygiene so that memory dumps, environment exports, and decoded payloads are not left behind.

Key takeaways

• Shai Hulud 2.0 shows that supply chain malware can convert CI runners and endpoints into NHI compromise surfaces.
• The decisive failure is not only exposure, but the continued validity of credentials after exposure.
• Governance now has to cover execution paths, credential lifetime, and revocation speed as one control problem.

Key terms

• CI runner: A CI runner is the execution environment that processes build, test, and deployment jobs. In NHI terms, it often holds privileged automation access, temporary credentials, and environment context that can be harvested if a malicious dependency or script executes during the pipeline.
• Credential reuse window: Credential reuse window is the period during which an exposed secret remains valid after disclosure. It matters because a leak is only actionable to defenders once the secret is revoked or rotated, and attackers will usually exploit the window before that happens.
• Runtime environment exposure: Runtime environment exposure is the leakage of secrets, tokens, or configuration from a system while code is executing, rather than from a stored file or committed repository. It is a core NHI risk because it bypasses many controls built around code review and secret scanning.

What's in the full article

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

• Decoded environment.json examples showing how double-base64 payloads exposed runtime memory snapshots
• Per-environment artifact breakdowns across CI jobs, developer endpoints, and cloud-connected machines
• Live credential validation details, including which secrets were still usable after disclosure
• Organisation-level attribution signals used to map affected environments back to real entities

👉 The full Entro blog includes decoded artifacts and environment-by-environment compromise examples

Deepen your knowledge

CI runner governance and secret lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for build pipelines and automation identities, it is worth exploring.