Shai Hulud 2.0 turned CI environments into NHI compromise paths

At a glance

What this is: This is an analysis of how Shai Hulud 2.0 used CI and developer environments as non-human identity compromise paths, with Entro Security tying exfiltrated data to 1,195 organisations and finding usable credentials days after disclosure.

Why it matters: It matters because identity teams cannot treat CI runners, developer endpoints and cloud machines as passive code-storage systems; they are execution environments with their own credential lifecycle, ownership and revocation burden.

By the numbers:

• Entro Security tied exfiltrated data to 1,195 organisations and found usable cloud and CI credentials more than 72 hours after disclosure.

Context

Shai Hulud 2.0 is best understood as a compromise of runtime environments, not just a repository event. The article shows that CI pipelines, developer endpoints and cloud-connected machines leaked in-memory secrets, local configuration and identity material that should have been governed as operational access, not merely as code artifacts.

That distinction matters for NHI governance because service accounts, tokens and cloud credentials have to be owned, scoped and revoked as living assets. When execution environments can be scraped during package installation or pipeline runtime, the governance boundary shifts from source control to the places where code actually runs.

Key questions

Q: What breaks when CI runners or developer endpoints are treated as harmless build infrastructure?

A: The main failure is that build infrastructure often contains live credentials, memory state and local configuration, so compromise of the execution environment becomes identity compromise. Secrets can be harvested without touching source control, and the attacker may walk away with cloud, chat, issue-tracker and service-account access that remains valid until explicitly revoked.

Q: Why do exposed CI credentials stay dangerous after the initial incident is public?

A: Public disclosure does not revoke access. If a credential is still valid, it can still authenticate to cloud or SaaS systems even after defenders know it was exposed. That is why exposure handling must include revocation, rotation and confirmation that the downstream identity can no longer be used.

Q: How do security teams know whether a CI or NHI exposure has really been contained?

A: Containment is real only when the exposed identities can no longer authenticate and the affected runners or endpoints no longer hold reusable secret material. Teams should verify revocation status, inspect where the credentials were used, and confirm that no surviving token, key or service account can still reach production-adjacent systems.

Q: What should teams do first after discovering that a CI pipeline may have exposed secrets?

A: The first response is to revoke and reissue any credentials, tokens, or keys that may have been exposed in the affected CI process. Teams should also verify the authenticity of build scripts and review repositories, docker images, and pipeline logs for hard coded secrets. Rapid secret rotation reduces the window for reuse while investigation continues.

Technical breakdown

How CI preinstall execution turns dependencies into secret-exposure paths

The article shows Shai Hulud 2.0 executing during the npm preinstall phase, which matters because package installation runs before many runtime checks and often with broad environment access. At that moment, the malicious dependency can read process environment variables, local configuration and memory context. In CI, that means the pipeline is not just building software; it is also holding active identity material for cloud, chat and issue-tracking systems. Once those values are present in the job context, exfiltration can happen without needing to break the platform itself.

Practical implication: treat dependency-install steps as credential-bearing execution points, not harmless build plumbing.

Why environment dumps are more valuable than secrets.json files

The article distinguishes between the loot collected into secrets.json and the underlying runtime data in environment.json. That is a critical technical point: the attacker did not only harvest discrete secrets, but also memory snapshots, hostnames, tenant identifiers and package context that help attribute and validate the environment. This is why repository cleanup alone is insufficient. If the runtime image, self-hosted runner, developer machine or container still exposes process state, the real compromise surface remains intact even after a malicious repository is removed.

Practical implication: govern runners and developer endpoints as identity-bearing systems whose memory and local state require containment.

How valid credentials remain usable after public disclosure

Entro reports that some credentials were still valid more than 72 hours after disclosure, which shows the difference between visibility and revocation. Discovery tells you what was exposed, but it does not invalidate access on its own. In NHI terms, the problem is persistent credential authority: tokens, API keys and service account credentials can continue to authenticate until the owning system explicitly revokes or rotates them. That creates a post-exposure window where the attacker does not need new compromise techniques, only working credentials.

Practical implication: use exposure detection as the trigger for revocation workflows, not as evidence that the risk is already closed.

Threat narrative

Attacker objective: The attacker’s objective was to harvest and preserve usable identity material from CI and developer environments so it could be reused for downstream access across cloud and enterprise systems.

1. Entry occurred through a compromised npm dependency that executed during the preinstall phase in CI and developer environments, giving the payload access to process context and local state.
2. Credential harvesting followed as the malware collected environment variables, in-memory secrets, runner tokens and cloud credentials into exfiltration artifacts such as environment.json and secrets.json.
3. Escalation and reach expanded because the harvested material included service account keys, cloud access keys and integration tokens that could authenticate into adjacent systems outside the original build job.
4. Impact was broad exposure across banks, governments and Fortune 500 technology organisations, with some credentials still usable days after public disclosure.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

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

NHI Mgmt Group analysis

Runtime environments, not repositories, were the real compromise surface: The article shows that Shai Hulud 2.0 used GitHub repositories as a collection layer, while the actual victims were CI pipelines, developer endpoints and cloud-connected machines. That distinction matters because governance anchored to source control misses the place where secrets actually live at execution time. For identity programmes, the practical conclusion is that runtime access has to be treated as the first-class asset.

Ephemeral execution breaks the assumption that secrets only need repository hygiene: This campaign succeeded because environments exposed live tokens, memory snapshots and local configuration while code was running. That is not the same as a static secrets leak in a codebase. The implication is that NHI governance cannot stop at scanning code or blocking commits; it has to account for the identity material present in each execution context.

Invalidation window is now the control boundary for NHI governance: The article’s 72-plus-hour validity finding shows that detection and disclosure do not equal revocation. A credential remains operational until the authoritative system invalidates it, regardless of how widely the leak is known. Practitioners should therefore treat post-exposure invalidation as the measure of control, not the speed of incident awareness.

Named concept: execution-environment secret drift: CI and developer environments accumulate identity material that outlives the job that used it. Shai Hulud 2.0 demonstrates that the longer those environments remain trusted, the more likely exposed secrets are to remain valid and reusable. The practical conclusion is that teams need to govern where secrets appear, not just where they are stored.

Shai Hulud 2.0 is a warning about NHI ownership, not just malware delivery: The article explicitly calls for treating non-human identities as managed assets with owners, scope and rotation. That is the right governance direction because the failure was not only exposure but lack of fast accountability for the identities hidden inside execution environments. The practical conclusion is that NHI lifecycle ownership must extend into build and runtime estates.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Secrets Management Guide

What this signals

Execution-environment secret drift: CI systems and developer endpoints are not just places where code runs, they are places where identity material accumulates and persists. Once those environments can leak memory, hostnames and tokens in the same job, the governance problem moves from source control to runtime containment.

The programme-level signal is that NHI ownership has to extend into build and runner estates. Teams should expect incident response to start with credential invalidation and ownership tracing, not with repository cleanup alone, because the attacker’s useful artefact is often the credential, not the code.

For practitioners

• Restrict secrets in CI runtime contexts Reduce the number of long-lived credentials available to package install steps, build jobs and developer shells so a single execution context cannot expose multiple downstream identities.
• Inventory identities tied to runners and endpoints Map each token, service account key and cloud credential to the runner, machine or user that used it, then assign an accountable owner for revocation and rotation.
• Shorten credential validity after exposure Establish an incident path that rotates or revokes cloud and CI credentials as soon as exposure is detected, rather than waiting for manual review to complete.
• Separate build-time and production-adjacent access Keep production-adjacent tokens, API keys and chat or issue-system credentials out of general-purpose CI jobs unless the workflow genuinely requires them and can be tightly scoped.
• Review self-hosted runner trust boundaries Treat self-hosted runners as sensitive execution assets that can expose memory, environment variables and local configuration, and scope their access accordingly.

Key takeaways

• Shai Hulud 2.0 exposed a governance blind spot where CI and developer environments became identity compromise paths rather than simple build assets.
• The article ties exfiltrated data to 1,195 organisations and shows that some cloud and CI credentials remained usable more than 72 hours after disclosure.
• The control that matters most is rapid invalidation of exposed credentials, backed by clear ownership of the runners, endpoints and service accounts they came from.

Key terms

• Execution Environment Secret Drift: The accumulation of reusable credentials, tokens and local configuration inside CI jobs, runners and developer endpoints that outlives the task that created it. In practice, it means the environment becomes a hidden identity store, so compromise of the runtime can expose secrets that were never meant to persist there.
• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.
• Credential Invalidation: Credential invalidation is the act of making a leaked password, token, API key, or certificate unusable after exposure or compromise. For identity programmes, it is the point where detection becomes containment, and it must be tied to ownership, approval, and evidence of success.
• NHI Ownership Transfer: NHI ownership transfer is the reassignment of a non-human identity from one employee to another during a change event such as offboarding. It is used when the credential still supports a live business process and cannot simply be revoked. Effective transfer requires context, dependency mapping, and governance approval.

Deepen your knowledge

NHI governance, secrets management, and workload identity security 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.