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

At a glance

What this is: A supply chain attack on the npm account atool poisoned hundreds of package versions and turned build-time execution into a credential-theft path across CI/CD and cloud identities.

Why it matters: It matters because NHI, workload, and developer identities are now exposed through the same package-install and pipeline trust model, so IAM, PAM, and secrets governance have to meet the build system where it executes.

By the numbers:

• The attack published 637 malicious package versions in a single 22-minute burst.
• The affected packages were collectively downloaded approximately 16 million times per week.
• Within hours of the attack, over 2,500 public GitHub repositories were created using exfiltrated tokens as additional dead-drops.

👉 Read Orca Security's analysis of the Mini Shai-Hulud npm supply chain attack

Context

Mini Shai-Hulud is a supply chain compromise in which malicious code executes during npm install, not after a user logs in or a service authenticates. That matters for identity teams because the attack path begins in the software delivery pipeline, where trust is often granted to packages, runners, and tokens before any runtime authorization decision is made.

The incident shows how non-human identities, developer credentials, and CI/CD secrets collapse into one exposure surface once lifecycle controls are weak. When package publishing, workflow tokens, cloud keys, and editor hooks all sit inside the same trust boundary, a single poisoned dependency can become a credential harvesting and propagation event.

Orca Security describes this as Wave 5 of the “Mini Shai-Hulud” campaign, and the starting position is not atypical for modern supply chain attacks. What is unusual is the scale of credential types stolen and the speed with which the malware moved from package compromise to broader repository abuse.

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: How do security teams know whether package installation risk is under control?

A: Look for three signals: scripts are blocked or tightly governed during install, runner memory and local secrets are minimized, and package provenance is checked before deployment. If developers can still install arbitrary lifecycle hooks with broad credentials present, the risk is not under control. Strong secrets hygiene alone is not enough if execution itself remains trusted.

Q: How should teams respond after a poisoned package is detected in their pipelines?

A: Contain the build environment first, then rotate any secrets that may have been present in memory, files, or tokens during install. After that, review repository branches, workflow files, and any unexpected package publication activity. The goal is to stop credential reuse and persistence before the compromise spreads into adjacent systems.

Technical breakdown

npm lifecycle hooks as the entry point

The payload executes through preinstall scripts, which run automatically when a package is installed. That means the attacker does not need a user to open a file or approve a prompt. By placing obfuscated JavaScript inside a package version, the malicious code inherits the trust that developers and CI systems already assign to dependency installation. The use of the Bun runtime helps the payload execute quickly and consistently across environments, while the package ecosystem itself becomes the delivery channel.

Practical implication: Treat package install as code execution, and restrict scripts during installation in build and developer workflows.

Secrets harvesting from runner memory and files

The malware reads GitHub Actions runner process memory through /proc/[pid]/mem, which lets it capture plaintext secrets before log masking can hide them. It then searches more than 130 file paths to collect AWS keys, GCP service accounts, Azure service principals, GitHub PATs and OIDC tokens, npm tokens, Kubernetes tokens, Vault credentials, SSH keys, and database strings. This is a direct reminder that secrets are not only stored in vaults or environment variables. They also exist in memory, on disk, and in ephemeral pipeline state.

Practical implication: Reduce the lifetime and placement of secrets inside runners, developers' machines, and build containers.

Dual-channel exfiltration and self-propagation

Stolen data is encrypted with AES-256-GCM and RSA-OAEP, then exfiltrated either through GitHub repository branches or through HTTPS traffic disguised as OpenTelemetry traces. The malware also creates persistence in AI coding assistants, IDE settings, and system services, while searching for tokens that can be exchanged for new publish rights. That turns a single package compromise into a worm-like propagation model, where stolen credentials help publish more malicious packages and expand reach.

Practical implication: Monitor for suspicious branch creation, token reuse, and unexpected package publication paths across the delivery chain.

Threat narrative

Attacker objective: The attacker sought to harvest reusable credentials, establish persistence in developer and pipeline environments, and use those secrets to propagate the compromise across the npm supply chain.

1. Entry occurred when attackers compromised the npm account atool and published malicious package versions that executed automatically through npm lifecycle hooks during install.
2. Credential access occurred as the payload scraped GitHub Actions runner memory and searched local file paths for cloud keys, GitHub tokens, npm publish tokens, and other secrets.
3. Escalation occurred when stolen tokens were used to create additional repositories, set up persistence, and support further malicious package publishing across the supply chain.
4. Impact was the theft of CI/CD and cloud credentials, plus the ability to backdoor development environments and extend the compromise into adjacent projects and repositories.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Build-time trust is now an identity control surface, not just a software delivery concern. This compromise worked because package installation was treated as a low-risk mechanical step rather than an execution event with identity consequences. Once npm preinstall hooks can read memory, steal tokens, and publish onward, the boundary between dependency management and identity governance disappears. Practitioners should treat package install paths as governed execution points, not passive delivery plumbing.

Secrets sprawl across CI/CD, developer tooling, and cloud identities creates a single blast radius. The attack harvested AWS keys, GCP service accounts, Azure principals, GitHub tokens, npm tokens, Vault data, SSH keys, and database strings from one execution path. That breadth matters because compromise of one pipeline identity can now expose many downstream identities at once. The practitioner conclusion is that secrets governance must be measured by lateral reach, not just by inventory count.

Ephemeral build trust debt: The attack shows that temporary runner sessions still accumulate durable identity risk when they can mint publish rights, reuse tokens, and create persistence. This is not a tool failure alone. It is a governance gap created when short-lived execution is assumed to be low consequence. The implication is that build systems need lifecycle-aware identity controls even when the workload itself is brief.

Credential masking is not control if the attacker can read process memory directly. Log masking and output filtering did not matter once the payload accessed runner memory and local files. That failure mode is specific and important: the control that failed was not secret redaction, but the assumption that secrets only become visible through logs or prompts. Practitioners should reframe pipeline defense around memory exposure and token scope.

Supply chain compromise now behaves like identity propagation. The attacker did not stop at package poisoning. Stolen credentials were reused to create repositories and support further distribution, which turns identity theft into a propagation mechanism. In governance terms, that means package trust, token authority, and publishing rights must be analysed together. Teams should expect compromise chains that move from code ingestion to identity abuse in one session.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Secret remediation is not just slow. 44% of developers are reported to follow security best practices for secrets management, which shows the gap is behavioural as well as technical.
• For a broader breach lens, 52 NHI Breaches Analysis helps teams connect stolen secrets to the repeatable control failures that let identities outlive their intended trust boundary.

What this signals

Build pipelines are becoming identity systems in their own right. When package installation can execute code, read memory, and mint new publishing rights, the delivery toolchain is no longer separate from identity governance. That is why control design has to shift from package approval to execution governance, with lifecycle visibility across runners, tokens, and downstream repositories.

Ephemeral does not mean low risk if the session can create durable identity state. A short-lived build job can still expose reusable secrets and trigger persistent access elsewhere. The practical shift is to measure whether a pipeline can create identity artefacts that outlive the job itself, not just whether the job terminates cleanly.

Security leaders should treat compromised packages as an identity event, not only a software integrity event. The operational question is whether detection, revocation, and rebuild processes can move faster than the compromise can publish, propagate, and persist. That is the standard now, especially in environments that rely on GitHub Actions and npm.

For practitioners

• Block script execution during dependency installs Use install modes that suppress lifecycle scripts in build and validation paths, and only allow scripts in controlled, reviewed pipelines. Treat npm preinstall and similar hooks as executable content, not metadata.
• Reduce token scope in CI/CD runners Remove broad publish and cloud permissions from runners unless a workflow truly requires them, and prefer short-lived credentials with explicit task scope. The smaller the token surface, the less useful a stolen secret becomes.
• Inventory exposed identities across the delivery chain Map where GitHub PATs, OIDC tokens, npm tokens, cloud keys, Vault credentials, SSH keys, and database strings can appear in developer and build environments. Cross-check that inventory against the package names and versions used in active pipelines.
• Watch for persistence in developer tooling Search for unexpected hooks in AI coding assistants, IDE configs, and system services, especially when incident response begins with a compromised package. Persistence in .claude, .vscode, systemd, or LaunchAgents signals that the compromise moved beyond simple package execution.
• Use exposure context to prioritise remediation Focus first on internet-accessible, high-criticality environments that reference affected npm packages, then expand to internal build servers and developer workstations. Asset criticality and runtime reachability should drive the order of cleanup, not package counts alone.

Key takeaways

• Poisoned npm packages can turn ordinary dependency installs into credential-harvesting events across CI/CD, cloud, and developer tooling.
• The impact was broad because one execution path exposed many identity types, including tokens, service accounts, keys, and repository access.
• Teams need to govern package installation, runner memory, and token scope together, or supply chain attacks will keep turning build trust into identity compromise.

Key terms

• Package install execution: Package install execution is the point at which dependency installation runs code on a developer machine or build runner. In supply chain attacks, that execution step becomes the entry point for secret theft, persistence, and propagation because it inherits trust before the workload is fully inspected.
• CI/CD secret exposure: CI/CD secret exposure occurs when tokens, keys, or credentials become accessible inside build and deployment systems. Those secrets may exist in environment variables, memory, files, or tool configurations, which means compromise can spread beyond one pipeline into cloud and repository access.
• Token scope: Token scope is the set of actions and systems a credential can reach. In non-human identity governance, narrow scope limits blast radius, while broad scope lets a stolen token publish packages, access cloud services, or mutate repositories far beyond its intended purpose.
• Persistence artifact: A persistence artifact is any file, hook, service, or configuration that lets malware survive after the initial execution window ends. In build and developer environments, these artifacts often hide in editor settings, system services, or startup hooks and can reactivate the compromise later.

Deepen your knowledge

Package install execution and CI/CD secret exposure are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for build systems that already carry cloud and publishing rights, it is worth exploring.

This post draws on content published by Orca Security covering the Mini Shai-Hulud npm supply chain attack: LLMjacking: How Attackers Hijack AI Using Compromised NHIs. Read the original.