Mini Shai-Hulud shows how npm supply chains steal CI/CD secrets

At a glance

What this is: Orca Security describes a supply chain attack that used a compromised npm account and malicious package versions to steal CI/CD and cloud secrets at scale.

Why it matters: IAM, PAM, and NHI teams need to treat build systems, package registries, and runner identities as governed access paths because trusted pipelines can become exfiltration channels.

By the numbers:

• The attack poisoned over 600 versions of 323 widely-used packages, according to Orca Security.
• Those packages were collectively downloaded approximately 16 million times per week, according to Orca Security.
• The attacker published 637 malicious package versions in a single 22-minute burst, according to Orca Security.
• The malware harvested credentials from over 130 file paths covering cloud, GitHub, Kubernetes, Vault, SSH, and database secrets, according to Orca Security.

Context

Mini Shai-Hulud is a software supply chain attack against npm package trust, where malicious code is inserted into package versions and executed during installation or build steps. In this case, the core issue is not just poisoned code, but the identity and secret surface exposed when CI/CD runners, developer tools, and package publishing workflows are trusted by default.

For identity teams, the important shift is that build pipelines now behave like high-value access brokers. When npm install, GitHub Actions runners, and developer environments can read credentials, mint tokens, or publish packages, the pipeline itself becomes part of the identity control plane rather than a purely engineering concern.

The incident is typical of modern supply chain abuse in one sense and unusual in another: package-level compromise is familiar, but the breadth of CI/CD secret harvesting and self-propagation makes the blast radius unusually large.

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 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 signs suggest a supply chain worm is using build identities for propagation?

A: Look for unexpected package publication, unauthorized repository creation, suspicious dependency updates, new branches or commits that look like maintenance noise, and repeat secret access from build environments. If those signals appear together, the compromise is behaving like a propagation mechanism rather than a single theft event.

Q: How should teams respond when package trust is compromised in CI/CD?

A: Treat the incident as both a software supply chain event and an identity incident. Remove persistence first, quarantine affected runners, revoke and reissue exposed credentials, and then rebuild from known-clean package versions before restoring normal pipeline operation.

Technical breakdown

How the npm lifecycle hook became the entry point

The malware executed through npm lifecycle hooks, specifically preinstall scripts, which run automatically during package installation. That matters because the install step is often treated as a low-friction dependency action rather than a privileged execution event. Once code runs in that context, it inherits the environment of the developer machine or CI runner, including access to filesystem secrets, environment variables, and local tokens. In this attack, the payload was delivered as obfuscated JavaScript and executed via Bun, showing that the package manager boundary is not the same thing as an execution boundary.

Practical implication: treat package installation as code execution and restrict scripts during dependency hydration.

How CI/CD secrets were extracted from runner memory and files

Orca Security reports that the payload read GitHub Actions runner process memory directly through /proc/[pid]/mem, which lets malware inspect live process memory rather than waiting for secrets to appear in logs or config files. It also harvested credentials from more than 130 file paths, including cloud keys, service accounts, SSH keys, database strings, and npm tokens. This is a broad secret-gathering pattern, not a single-token theft, and it bypasses log masking because the secrets are taken before masking matters.

Practical implication: segment runner identities and remove persistent secrets from build-time environments wherever possible.

How the worm used dead-drops and persistence to spread

The campaign combined exfiltration with persistence and propagation. Stolen data was encrypted, then written either into branches in a legitimate GitHub repository or sent to a fallback HTTPS endpoint disguised as telemetry traffic. The malware also planted hooks in AI coding assistants, IDE task files, and operating system daemons, while polling GitHub for attacker commands. That makes the incident a supply chain worm rather than a one-off steal-and-leave event, because compromised identities and tokens were used to seed additional compromise.

Practical implication: assume a compromised build identity can become a propagation mechanism and inspect persistence paths before rotating credentials.

Threat narrative

Attacker objective: The attacker aimed to steal high-value credentials from CI/CD and developer environments, then use them to propagate further compromise through trusted software supply chains.

1. Entry occurred when malicious npm package versions executed automatically through install-time lifecycle hooks in CI/CD and developer environments.
2. Credential harvesting followed as the payload read runner memory and over 130 file paths to collect cloud, registry, and workstation secrets.
3. Escalation and lateral movement occurred when stolen tokens were used to create new repositories, publish additional artifacts, and maintain persistence through local hooks and daemons.
4. Impact was broad credential exposure across build systems, cloud platforms, and package namespaces, with self-propagation risk across downstream software supply chains.

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).
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

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

Build-time trust is now an identity problem, not just a supply chain problem. The attacker did not need to break runtime application controls when the package install path already carried execution privilege and secret access. That shifts governance from code provenance alone to the identity of the runner, the publishing workflow, and the secrets available during installation. Practitioners need to treat build-time trust as governed access, not assumed trust.

Secret exposure in CI/CD is no longer bounded by logs or vault policy when runners can read live memory. The use of /proc/[pid]/mem shows that masking controls only help after a secret is already observable, which is too late in this class of attack. The breach demonstrates that environment-level access in pipelines must be managed as a credentialed identity surface, not a transient engineering convenience. The practitioner conclusion is that runner memory and ephemeral token scope matter as much as repository permissions.

Mini Shai-Hulud is a supply chain worm because credentials were the propagation substrate. Once stolen tokens could publish packages, create repositories, and access cloud tooling, the attacker no longer needed separate footholds for each stage. That is the defining governance failure: one compromised package trust path became a reusable identity bridge into many others. The field should read this as a warning that package ecosystems can become identity distribution systems when offboarding, rotation, and scope containment are weak.

Ephemeral build identities still need lifecycle governance. The common assumption is that CI/CD credentials are short-lived enough to be inherently safer, but that assumption fails when the same session can read, exfiltrate, and repurpose multiple secret types before any review cycle begins. The implication is that pipeline identity cannot be governed only by expiration time; access scope, runtime isolation, and secret provenance have to be controlled at issuance.

Identity blast radius is the right concept for modern supply chain incidents. The article's scale data shows that a single compromised npm account can cascade into hundreds of package versions and millions of weekly downloads. That is not merely an exposure count, it is the measurable spread of trust across publishing, build, and cloud identities. Practitioners should use blast radius as the primary risk lens when deciding where to harden first.

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.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius now belongs in supply chain reviews. When package installation can expose runner memory, registry tokens, cloud service principals, and publish rights in one path, the control question changes from "is the code trusted?" to "how far can one build identity move before it is contained?" That is a governance issue for CI/CD, not only a developer hygiene issue.

Secret sprawl and build sprawl are converging. NHI Mgmt Group research shows that 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. This incident shows why that exposure pattern becomes dangerous when the build pipeline itself is compromised.

Supply chain telemetry must include identity signals. A package can be valid, signed, and still become a credential-theft vehicle if its install-time behaviour changes. Teams should therefore watch for package publication anomalies, runner memory access, and unexpected token use as part of the same detection story.

For practitioners

• Harden package installation paths Run dependency installs with scripts disabled where feasible, and isolate any package execution that must occur during build steps. Review pipelines that allow automatic lifecycle hooks to execute with broad environment access.
• Remove persistent secrets from runners Replace long-lived credentials in CI/CD environments with short-lived, scoped tokens and ensure build jobs cannot read unrelated cloud or registry secrets from memory or disk.
• Rotate exposed credentials in a strict order Revoke and regenerate package registry tokens, cloud keys, GitHub secrets, Kubernetes credentials, SSH keys, and database access after confirming persistence hooks are removed.
• Inspect developer and build endpoints for persistence Check editor hooks, system services, and daemon processes on machines that handled affected packages, because the payload can survive credential rotation if the local foothold remains.
• Map package usage to critical pipelines Identify which build systems, production deployments, and developer environments consume affected libraries so remediation can start with the highest-risk identities and the most exposed execution paths.

Key takeaways

• A poisoned npm package can turn trusted build steps into credential-extraction points, which makes CI/CD identity a first-class attack surface.
• The incident scaled across hundreds of package versions and millions of weekly downloads, showing how quickly a single account compromise can become ecosystem-wide exposure.
• The practical control gap is not only package provenance. Teams need stronger isolation, script restrictions, secret minimisation, and fast credential revocation in build environments.

Key terms

• Build-Time Trust Boundary: A build-time trust boundary is the line that separates dependency installation and compilation from access to sensitive credentials or production systems. When that boundary is weak, malicious packages can turn routine automation into a path for broader compromise.
• Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
• Runner Memory Exposure: Runner memory exposure is the risk that secrets loaded during CI or build execution can be read from process memory, logs, or temporary state. It becomes especially dangerous when attackers can execute code inside trusted workflows and recover short-lived tokens before they expire.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.