Shai-Hulud supply chain attacks expose the limits of CI trust

At a glance

What this is: This is a supply chain attack analysis showing that Shai-Hulud abused CI trust, stole credentials from build environments, and used them to keep propagating through npm and GitHub.

Why it matters: It matters because CI runners, tokens, and cloud credentials are now part of the identity perimeter, so IAM and NHI controls must extend into build and publication workflows.

Context

Shai-Hulud is a self-propagating npm supply chain attack that turned trusted build activity into a credential-harvesting path. The security gap is not just malicious code in a package, but the assumption that CI environments are inherently trustworthy once a build starts.

For IAM and NHI programmes, the important shift is that npm tokens, GitHub Actions runners, and cloud access keys behave like identities with lifecycle and privilege. If those identities are not inventoried, constrained, and monitored, package cleanup only removes the payload, not the access path.

Key questions

Q: What should security teams do after a supply-chain worm reaches developer tooling?

A: Containment has to start with rebuilding affected developer and CI environments from trusted images, then rotating every credential the environment could have exposed. Teams should also block unreviewed configuration-only changes and revalidate publishing permissions, because the same attack path can be used to republish infected packages or steal workflow secrets.

Q: Why do supply chain attacks create such large blast radius?

A: They create large blast radius because one upstream compromise can be reused across many downstream relationships. A software update, contractor account, or managed service can be trusted by dozens or thousands of organisations at once. When that trust is abused, the attacker does not need to break each target individually, which makes scale the defining feature.

Q: What are the signs that a CI/CD runner has been used as persistence?

A: Look for unfamiliar workflows, new repository-level automation, unusual runner registration activity, and logs showing self-hosted execution tied to suspicious repository events. In this pattern, persistence is not a stolen password, but a workflow that keeps reintroducing attacker-controlled code into trusted build infrastructure.

Q: How should teams respond when package compromise exposes cloud credentials?

A: Contain the affected runtime first, then revoke and rotate the exposed cloud credentials, review metadata service access, and inspect egress logs for exfiltration. The priority is to cut off reuse of the stolen identity material before the attacker can pivot into cloud services or downstream systems.

Technical breakdown

How Shai-Hulud turns package execution into credential theft

The worm uses lifecycle hooks to execute during installation, before many teams expect malicious behaviour. Once running, it reads secrets from environment variables and other build-time stores, then exfiltrates them through GitHub-linked infrastructure and workflow files. That matters because CI systems often inherit broad access to registries, source control, and cloud APIs, so one compromised package can reach multiple trust domains in one run. The mechanism is not a single exploit, but chained trust in package execution, secrets exposure, and automated publishing.

Practical implication: Treat package installation as an execution boundary and reduce the secrets available to build jobs.

Why GitHub Actions runners became a persistence layer

The campaign used self-hosted runner registration and rogue workflow files to preserve access after the initial infection. In practical terms, that turns a CI platform into an attacker-operated command path because legitimate automation infrastructure is reused for malicious execution. This is harder to detect than a conventional backdoor because the traffic, identity, and command path can all look like normal platform activity. The important architecture lesson is that runners are not just compute, they are privileged identity-bearing systems.

Practical implication: Audit runner enrollment, workflow changes, and privileged GitHub actions as if they were account creation events.

Why signature-based detection misses fast-moving npm worms

Shai-Hulud changed runtime behaviour, payload shape, and execution timing across variants, which weakens malware signatures and static allowlists. Behavioural detection is more durable because the attack must still perform a small set of actions: read credentials, make unusual outbound connections, and publish or modify packages. In supply chain environments, the invariant is the attacker workflow, not the file hash. That is why detection has to correlate runner activity, package install events, and downstream cloud API use across telemetry sources.

Practical implication: Build detections around process lineage, secret access, and publishing behaviour rather than file signatures alone.

Threat narrative

Attacker objective: The attacker objective was to harvest usable credentials and convert a package compromise into repeated downstream access across the software supply chain.

1. Entry occurred when maintainers were phished or tricked into revealing credentials that allowed the malicious package path to begin.
2. Credential harvesting happened inside build and developer environments as the payload read environment secrets, GitHub tokens, and cloud keys.
3. Escalation and propagation followed when stolen npm tokens and GitHub infrastructure were used to publish the next wave of compromised packages.
4. Impact was persistent compromise across npm, GitHub, CI runners, and cloud access paths, even after the original package was removed.

Breaches seen in the wild

• 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.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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

CI trust is now an identity problem, not just a software integrity problem. Shai-Hulud showed that package execution can inherit secrets, publish privileges, and cloud reach in one workflow. That means CI runners and tokens must be governed as identities with scope, ownership, and offboarding, not treated as disposable build plumbing. The practical conclusion is that supply chain resilience starts with identity containment.

Runner persistence creates a hidden privilege layer inside DevOps. Self-hosted runners and workflow files can function like durable access points even when a malicious package is removed. That is a governance gap because most organisations review code more often than they review automation identities. The named concept here is runner trust sprawl: the accumulation of privileged automation paths that outlive the package event itself. Practitioners need to treat runner enrolment and workflow mutation as high-risk control points.

Behavioural detection is the only durable answer when payloads mutate. The article makes clear that the same attack logic can survive changes in language runtime, hook timing, and file structure. This is why static signatures underperform against supply chain worms. The control problem is not just malware detection, but recognising the invariant sequence of secret access, outbound communication, and unauthorised publication.

Third-party exposure turns every exposed NHI into a supply chain liability. The article's core warning is that credentials embedded in CI, GitHub, and cloud integrations can be reused beyond the original environment. That aligns directly with NHI governance: ownership, rotation, and revocation are the controls that determine whether a compromise stays local or becomes ecosystem-wide. The practitioner takeaway is to govern delegated access as a lifecycle, not a one-time trust grant.

Package cleanup is an incomplete response when identity material remains live. Removing a bad package may stop further installation, but it does not revoke runner registrations, API keys, or federated access already issued. That creates a false containment signal. Security teams need to assume that the compromise boundary extends to every identity touched by the build path until it is explicitly revalidated.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Shai-Hulud shows why build systems now need identity governance. The attack worked because CI secrets, runner credentials, and publishing tokens were treated as operational by-products rather than governed identities. Once those identities are exposed, the supply chain becomes a propagation channel instead of a control boundary.

Runner trust sprawl: privileged automation paths in CI can outlive the package compromise that created them. For practitioners, that means lifecycle controls, offboarding, and runtime monitoring must cover GitHub runners, package tokens, and federated cloud access together.

Security teams should watch for a shift from package-centric detection to behaviour-centric control design. The practical test is whether your telemetry can connect install-time execution, secret access, workflow mutation, and cloud API use into one incident timeline.

For practitioners

• Inventory build-time identities and secrets Map npm tokens, GitHub PATs, cloud keys, and service accounts used by CI jobs, then identify which ones can reach registries, source control, and cloud APIs.
• Constrain package installation privileges Use pinned versions, npm ci, and minimal secrets exposure during install so a compromised dependency cannot read broad environment variables or publish credentials.
• Audit GitHub workflow and runner persistence Search for unexpected workflow files, self-hosted runner registrations, and direct-push changes that could preserve access after the initial package is removed.
• Rotate every credential touched by a compromised pipeline Revoke classic npm tokens, rotate GitHub and cloud access credentials, and assume any secrets present in affected build environments were exposed.
• Detect on behaviour across CI, GitHub, and cloud logs Correlate process execution, outbound connections, workflow edits, and cloud API events so the alert logic follows the attack pattern rather than the malware file.

Key takeaways

• Shai-Hulud exposed a failure mode where package execution, secrets exposure, and automation persistence combine into one supply chain compromise.
• The attack spread across CI, GitHub, npm, and cloud access paths, which is why cleanup has to include token revocation and runner review.
• Behavioural detection and identity lifecycle control are the two controls that matter most when payloads can mutate without changing the attack pattern.

Key terms

• Self-propagating worm: A self-propagating worm is malware that automatically spreads from one compromised system to another without waiting for a human operator to copy it. In software supply chains, propagation often happens through trusted accounts, package registries, or update channels that the worm can reuse.
• CI Runner Persistence: CI runner persistence is the use of build or automation infrastructure to maintain access after the initial compromise. It matters because runners can execute commands, retrieve secrets, and trigger workflows under trusted operational conditions, which makes them a durable foothold if not explicitly monitored and offboarded.
• Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.
• Build-time identity: Build-time identity is the set of service accounts, tokens, and permissions used by CI/CD systems, testing tools, and deployment automation. It matters because these identities often carry production access and can turn development speed into an access-control problem if they are over-privileged or poorly governed.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps security and identity practitioners strengthen governance for machine identities, secrets management, and access lifecycle control.