Mini Shai-Hulud shows how npm worms turn CI/CD secrets into infrastructure

At a glance

What this is: A new Mini Shai-Hulud npm campaign is abusing compromised packages to steal CI/CD secrets from runner memory and turn stolen tokens into public GitHub infrastructure.

Why it matters: It matters because CI/CD secrets, build runners, and publishing tokens can become a single attack path, which changes how IAM, secrets, and pipeline controls have to be governed.

By the numbers:

• Over 2,200 public GitHub repositories had already been created using exfiltrated tokens.
• The attack unfolded in two coordinated waves on May 19, 2026, with all malicious packages published within a compressed window.

Context

Mini Shai-Hulud is a supply chain worm pattern, not a single-package defect. It exploits trust in npm publishing, CI/CD execution, and inherited runner privileges to move from a malicious dependency into secrets theft and then into downstream infrastructure use. The identity angle is real because the stolen assets are non-human credentials, not just code.

This wave shows why secrets governance cannot stop at vault placement or rotation policy. When build runners can expose masked secrets in memory and stolen tokens can publish new infrastructure, the control boundary has to cover package provenance, runner isolation, and token lifecycle together.

Key questions

Q: What breaks when a malicious npm package can read CI/CD runner memory?

A: When a malicious package can read runner memory, secret masking no longer protects credentials because plaintext tokens are already present in process space. That breaks the assumption that build-time secrets are safe if they are not written to disk. The immediate result is cloud, GitHub, and Vault credential exposure inside the same execution context.

Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?

A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.

Q: What are the signs that a build token has been abused after exposure?

A: Unexpected repository creation, abnormal package publication, workflow edits, and outbound connections tied to runner hosts are strong indicators. In this pattern, the attacker does not stop at theft and immediately uses the token, so post-compromise monitoring has to look for identity activity, not only malware artefacts or failed logins.

Q: How should teams govern secrets in infrastructure as code pipelines?

A: Teams should keep secrets out of code and move them into a dedicated runtime secrets service, then enforce policy that prevents repository storage and console exposure. The goal is to make credential lifecycle controls independent from the IaC repository, so revocation, rotation, and access review can happen without editing infrastructure templates.

Technical breakdown

How the worm reaches runner memory

The malicious package runs through an npm lifecycle hook, which means installation time becomes execution time. In this case, the payload installs Bun if needed and then reads GitHub Actions runner process memory to recover secrets that were masked in logs. That matters because masking protects output, not memory. Once code runs inside the runner context, the process boundary is the real trust boundary, and any inherited credential in memory becomes harvestable if the attacker can spawn the right child process.

Practical implication: Treat CI installs as execution events and remove secret-bearing contexts from runners that can execute third-party package code.

How stolen CI/CD secrets become active infrastructure

Exfiltration is only the middle of the chain. The campaign uses stolen GitHub tokens to create thousands of public repositories as dead-drops, which turns credential theft into visible, attacker-controlled infrastructure. That behaviour is consistent with supply chain operators who want persistence, staging, or bulk exfiltration points. The important architectural point is that a token with publishing or repository rights is not just an authentication artefact, it is an infrastructure control if the attacker can reuse it immediately.

Practical implication: Scope CI/CD tokens so they cannot create repositories, publish packages, or access unrelated organisational assets.

Why build environments are now credential concentrators

CI/CD runners routinely aggregate cloud keys, registry tokens, Kubernetes credentials, and developer tooling secrets because they must authenticate to many services in one workflow. That concentration makes them high-value NHI targets. The problem is not merely that secrets exist in the pipeline, but that one compromised install can expose multiple identity domains at once. In practice, the runner has become a temporary identity broker, so compromise of that broker collapses the trust assumptions behind the whole build chain.

Practical implication: Inventory which non-human credentials are reachable from each build path and reduce the number of secret classes any one runner can touch.

Threat narrative

Attacker objective: The attacker’s objective is to harvest reusable CI/CD secrets and turn them into persistent infrastructure for further supply chain operations.

1. Entry occurs when a compromised npm package executes during installation in the CI/CD workflow, giving the payload code execution inside the runner context.
2. The payload reads Runner.Worker memory and harvests masked CI/CD secrets, then searches over 130 file paths to collect cloud, vault, wallet, and developer credentials.
3. Stolen GitHub tokens are then reused to create thousands of public repositories that act as dead-drops and proof of successful credential abuse.
4. Impact is downstream exposure of additional environments, repository creation at scale, and a widened blast radius across build, publishing, and cloud access paths.

Breaches seen in the wild

• 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).
• 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

Secrets in CI/CD are no longer just leaked, they are operationalised: once a workflow token can create repositories or publish packages, the secret has become infrastructure, not merely access. That changes governance from rotation-only thinking to lifecycle and blast-radius control. The control failure here is assuming that compromise ends at disclosure when, in practice, the stolen token becomes a reusable production capability.

CI/CD runner memory is a non-human identity exposure point: masked output did not protect the secrets because the payload read process memory directly. That is a classic example of why NHI governance must extend beyond vault location into execution-time exposure, especially where service accounts, cloud keys, and pipeline tokens converge.

Package provenance and execution context now need to be governed together: npm trust, workflow trust, and identity trust are no longer separable concerns in supply chain attacks of this kind. The same installation event can trigger code execution, secrets harvest, and token misuse in one chain. Practitioners should treat the install path as a policy enforcement point, not just a dependency resolution step.

Blast radius control is the deciding metric in modern supply chain defence: the article’s scale shows that the question is not whether a malicious package can execute, but how far the resulting identity compromise can propagate. For identity teams, that means tightening the relationship between CI/CD permissions, repository rights, and secret scope so one compromised runner cannot become many compromised systems.

Credential concentration in build systems is a structural risk, not an implementation flaw: runners often aggregate the exact secrets attackers want, which makes them attractive targets across npm, GitHub, cloud, and vault ecosystems. The practitioner conclusion is to design for minimal reachable credentials per job and assume build-time identity exposure is a primary attack surface.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, 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: Guide to the Secret Sprawl Challenge

What this signals

Secret concentration in CI/CD is the real accelerant: the attack succeeds because build runners routinely hold cloud keys, registry tokens, and repository credentials in one place. That means a single malicious install can turn into multi-system compromise before a team has time to review the package. The operational answer is to stop assuming the runner is a benign middle layer.

Runner identity is now part of the attack surface: 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs. The important implication is that exposed secrets are not an edge case, they are the expected condition practitioners must design around.

Package cooldown creates time for verification, but only if teams actually gate execution: attackers rely on the gap between publication and detection, so newly published versions need policy treatment before they reach runners. That is especially true where repository publication rights or CI token reuse could convert one compromise into many.

For practitioners

• Isolate package installation from secret-bearing workflows Run third-party dependency installs in build stages that do not hold cloud tokens, publishing rights, or long-lived vault credentials.
• Reduce CI token scope to the minimum publish path Remove repository creation, package publishing, and cross-repo permissions from CI/CD tokens unless a specific job requires them.
• Inspect runner memory exposure paths Review which workflows can access process memory, privileged shells, or debug tooling that can reveal masked secrets during execution.
• Block newly published or suspicious packages before execution Add cooldown or approval gates for newly released npm versions so malicious packages cannot run before they are analysed.
• Search for downstream token abuse and unauthorized repository creation Audit GitHub for unexpected repository creation, workflow changes, and token use patterns tied to compromised CI jobs.

Key takeaways

• Mini Shai-Hulud shows that npm supply chain compromise can move directly from package execution to CI/CD secret theft and token reuse.
• The attack’s scale matters because thousands of public repositories were created with stolen tokens, proving that exfiltration was only the first phase.
• Limiting runner exposure, shrinking token scope, and gating new package versions are the controls that most directly reduce the blast radius.

Key terms

• CI/CD runner: A CI/CD runner is the execution environment that performs build, test, or deployment jobs. It often has access to source code, tokens, and cloud credentials, which makes it a high-value identity surface when workflows are compromised.
• Repository Dead-Drop: A repository dead-drop is a public or attacker-controlled repository used to receive stolen data, tokens, or artifacts. Attackers use it to turn exfiltrated credentials into a persistent staging point that is easy to distribute, search, and automate against.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect build-system identity risk to the controls their programme already owns.