TL;DR: A new Shai-Hulud wave poisoned more than 800 npm packages and populated over 25,000 GitHub repositories with stolen secrets, while also creating persistent GitHub runners for remote access, according to Backslash Security. The incident shows that package trust, build automation, and secret handling remain inseparable NHI governance problems, not isolated developer hygiene issues.
At a glance
What this is: This is an analysis of the Shai-Hulud npm supply chain attack and its impact on NHI controls, showing how poisoned packages, stolen secrets, and rogue runners turned developer tooling into a persistence and exfiltration path.
Why it matters: It matters because identity teams have to govern package trust, build-time execution, and secret exposure together, or supply chain compromise will keep bypassing isolated controls.
By the numbers:
- Over 800 packages were poisoned in the latest Shai-Hulud wave.
Context
Shai-Hulud is a supply chain attack on the npm ecosystem that used poisoned packages to reach developer machines, CI pipelines, and automated build systems. The central identity security issue is not the package alone but the non-human credentials, tokens, and environment variables those execution paths expose.
For NHI programmes, this kind of incident collapses the usual separation between software delivery and identity governance. Package trust, build permissions, secret storage, and runner persistence all become part of the same control plane once malicious code can execute inside trusted automation.
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 compromised build runners and secrets create such a large blast radius?
A: Build runners often reuse persistent credentials across many repositories and environments, so one infected execution path can expose more than a single project. If the runner is not tightly scoped and quickly revoked, the attacker inherits a broad machine identity footprint that can be reused for further access.
Q: What are the signs that an npm supply chain attack has reached secret-exposure stage?
A: Look for unusual repository creation, rapid growth in secret-bearing artifacts, unexpected CI activity, and new runner registrations tied to package execution. Those signals indicate the attack has moved beyond code tampering into credential harvesting and persistence, which requires immediate token revocation and host triage.
Q: How should teams respond when a self-hosted repository exposes secrets?
A: Treat the repository as only one part of the problem. Revoke and rotate the exposed secrets, review the downstream SaaS and storage accounts they can reach, and verify whether other credentials were stored in the same location. Self-hosted systems demand the same lifecycle discipline as any production identity platform.
Technical breakdown
How poisoned npm packages become an identity problem
The attack chain begins when a trusted dependency is republished with malicious code and then executed through normal installation or preinstall hooks. At that point, the package is no longer just software delivery content. It is an execution vehicle inside environments that already hold secrets, tokens, and cloud access material. The important technical detail is that the malicious code does not need to break authentication first. It only needs to run where credentials are already present. That is why dependency trust becomes an identity control problem, not just a software integrity problem.
Practical implication: treat package execution paths as credential-bearing attack surfaces, not just build inputs.
Why secrets, runners, and build automation are linked
Once the malware executed, it harvested secrets from local environments and CI contexts, then created persistent GitHub runners for ongoing access. That combination matters because it converts a single execution event into both exfiltration and persistence. In identity terms, the attacker moved from temporary code execution to durable control of automation assets that are normally assumed to be trustworthy. The runner then becomes a non-human foothold, while the stolen credentials widen the blast radius into cloud and development systems. The result is a chained compromise across NHI assets that were never governed as one lifecycle.
Practical implication: govern runners, tokens, and build credentials as a single NHI estate with shared offboarding and revocation triggers.
Why public repositories became an exfiltration channel
Instead of sending stolen data to a traditional command-and-control endpoint, the malware uploaded secrets into newly created public GitHub repositories. That is technically important because it blends with normal platform behaviour and uses a trusted service as the transport layer. The exfiltration path therefore looks like ordinary collaboration activity unless you are watching for abnormal repository creation, secret density, and automation-linked write events. This is a governance failure as much as a detection problem, because the organisation has allowed public-code workflows to carry sensitive runtime identity material.
Practical implication: monitor for secret-bearing repository creation and restrict automation paths that can publish sensitive data externally.
Threat narrative
Attacker objective: The attacker aimed to steal usable secrets at scale while keeping persistent access inside trusted development automation.
- Entry occurred through compromised npm packages that were republished with malicious code and executed in developer and CI environments.
- Credential harvesting followed when the malware scanned hosts and pipelines for tokens, cloud keys, and environment variables.
- Escalation and persistence came from rogue GitHub runners and public repository uploads that preserved access and exfiltrated stolen material.
- Impact included exposure of secrets across affected projects and the need for broad credential rotation and repository cleanup.
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.
- Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Package trust has become an NHI governance boundary: The security question is no longer whether an npm package is signed or popular, but whether it can execute inside an environment that already contains machine credentials. That shifts the control boundary from software provenance alone to identity-bearing build and install paths. Practitioners should treat dependency execution as part of NHI governance, not a separate developer concern.
Standing build access creates identity blast radius: Build systems, runners, and installation hooks are often provisioned as if they are disposable, yet they frequently hold persistent tokens and cloud access. This attack shows that standing privilege in automation is enough to turn one compromised package into multi-environment exposure. The practical conclusion is that blast radius, not just package hygiene, defines the real control objective.
Persistent runners are a lifecycle failure, not a malware novelty: The rogue GitHub runner is the clearest sign that offboarding failed at the machine identity layer. If a build agent can be registered, used, and left behind without lifecycle enforcement, then the control assumption that automation is ephemeral has already collapsed. Practitioners need to recognize that the failure mode is unmanaged NHI persistence, not merely malicious code execution.
Secret exfiltration through public repositories is a governance blind spot: Public code platforms can be turned into storage for stolen credentials when organisations do not constrain where automation can write data. That creates an identity leakage path that bypasses classic perimeter thinking and makes repository governance part of secret governance. The implication is straightforward: secret handling and code publishing cannot be separated in modern supply chains.
Shai-Hulud exposes an identity supply chain problem: This is the specific named concept that best fits the incident. Identity supply chain means the chain of trust from package maintainer credentials through build automation to downstream secrets and runners. Once any step is compromised, the whole environment inherits the attacker’s identity foothold. Practitioners should manage that chain as a single trust domain.
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.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity supply chain governance is now a build requirement: When package execution, runner registration, and secret handling all sit in the same delivery chain, controls that treat them separately will miss the real compromise path. NHI programmes should define where trusted automation begins and ends, then enforce that boundary consistently across repositories, CI, and cloud access.
Public repository exfiltration changes how teams think about leakage: The problem is not only that secrets were stolen, but that they were published into infrastructure the organisation already trusted. That means repository permissions, automation write paths, and secret scanning now belong in the same risk conversation as credential rotation and offboarding. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
For practitioners
- Constrain package execution in build pipelines Block unnecessary preinstall and postinstall hooks, and only allow dependency execution in controlled pipelines that do not expose production secrets.
- Separate build identities from sensitive cloud access Use dedicated build credentials with tightly scoped permissions so a compromised package cannot reach cloud keys, deployment tokens, or environment secrets.
- Inventory and rotate exposed machine secrets Assume any host that ran a compromised package may have leaked tokens, API keys, or environment variables, then revoke and replace those credentials immediately.
- Detect rogue runner registration and abnormal repository creation Watch for new GitHub runners, unusual repository write activity, and secret-heavy public repositories created from automation contexts.
- Treat third-party package trust as a lifecycle issue Tie dependency approval, runner registration, and secret revocation to the same governance workflow so one compromise does not leave residual access behind.
Key takeaways
- This attack shows that a malicious package can become both an execution path and a credential-harvesting path inside trusted automation.
- The scale matters because more than 800 packages were poisoned and over 25,000 GitHub repositories were affected by stolen secrets.
- The control that would have reduced damage is lifecycle governance over build identities, runners, and exposed secrets, not just dependency approval.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack harvested secrets from developer and CI environments. |
| NHI-03 — Vulnerable Third-Party NHI | The incident started with poisoned third-party npm packages and maintainer access. | |
| NHI-05 — Overprivileged NHI | Rogue runners and build tokens expanded the blast radius of the compromise. | |
| Recommendation — Scan build paths for leaked NHI secrets and revoke any exposed credentials immediately. Review third-party package trust paths and limit what external dependencies can reach. Reduce build identity permissions so compromised automation cannot reach broad cloud access. | ||
| MITRE ATT&CK | TA0006; TA003 — Credential Access; Persistence | The malware harvested secrets and left behind durable access through GitHub runners. |
| Recommendation — Map package-compromise detections to credential access and persistence tactics in your monitoring. | ||
| CIS Controls v8 | CIS-5 — Account Management | The incident depended on unmanaged identities in build and runner environments. |
| Recommendation — Tighten account management for build identities and remove unused automation access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The attack exploited excessive trust in automation entitlements across the delivery chain. |
| Recommendation — Limit entitlements on build and runner identities to the minimum required for delivery. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credentials and tokens were the primary theft target in the infected environments. |
| Recommendation — Apply authenticator management to rotate and revoke machine credentials after any package compromise. | ||
Key terms
- Identity supply chain: An identity supply chain is the network of trusted accounts, roles, tokens, and delegated permissions that connect one system to another. When one link is compromised, attackers can inherit access downstream and use legitimate trust relationships to spread impact across environments.
- Rogue GitHub Runner: A malicious or unauthorized automation runner registered in a victim environment to preserve access after initial compromise. In practice it behaves like a persistent non-human identity with execution rights that outlive the original infection event.
- Secret Harvesting: Secret harvesting is the extraction of credentials, tokens, or keys from an execution environment rather than from an authentication flow. It often targets files, memory, environment variables, and local configuration, which makes trusted developer and CI contexts high-value targets.
- 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.
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.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org