Mini Shai-Hulud shows how npm supply chains become credential worms

At a glance

What this is: Mini Shai-Hulud is an active npm and PyPI supply chain worm that steals credentials, republishes compromised packages, and can trigger destructive persistence on developer systems.

Why it matters: IAM, NHI, and platform teams need to treat build pipelines, package registries, and CI runners as credential-bearing identities because trusted automation can become the infection path.

By the numbers:

• The attack affected 373 malicious package-version entries across 169 npm package names and 2 PyPI packages.
• The compromise reached over 160 additional npm and PyPI packages.

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

Context

Mini Shai-Hulud is a supply chain attack that turns trusted build and packaging identities into an infection path. The compromise started in GitHub Actions, moved through published package versions, and then used those same package install paths to steal more credentials and spread again.

For IAM and NHI programmes, the core problem is not just package tampering. It is that CI runners, GitHub tokens, npm tokens, cloud credentials, and Kubernetes service account tokens all sit inside the same delegated trust chain, so one poisoned workflow can propagate across developer and platform environments.

The article describes an active compromise affecting major package namespaces and multiple runtimes. That starting position is not atypical for modern software supply chains, where identity, build automation, and release processes are tightly coupled and often over-trusted.

Key questions

Q: What fails when package provenance is trusted too much in a supply chain compromise?

A: Provenance fails when the publishing identity is already compromised or attacker-influenced. A valid signature only proves that the package was published through an accepted workflow, not that the workflow, runner, cache, or token source was trustworthy. Security teams should validate the full release path, not the attestation in isolation.

Q: Why do short-lived OIDC tokens still create meaningful supply chain risk?

A: Short-lived tokens still create risk because attackers only need them during the brief window when they are present in memory or workflow state. If a runner can expose those tokens through process memory, logs, or cache poisoning, expiration alone does not prevent abuse. The control problem is runtime containment, not token duration.

Q: What should teams do when a package ecosystem attack reaches CI runners and developer workstations?

A: Teams should isolate the affected execution environments, identify persistence artefacts, and rotate every credential that may have been exposed, including GitHub, npm, cloud, and vault tokens. They should also inspect publish rights and recent package releases to determine whether the compromise propagated beyond the first infected host.

Q: How should security teams reduce the chance of another npm worm spreading through build identity?

A: They should separate build, test, and release identities; limit who can publish packages; and block workflows that allow untrusted code to influence trusted release paths. Continuous monitoring must cover package lifecycle hooks, runner memory exposure, and any identity that can mint or reuse publishing credentials.

Technical breakdown

GitHub Actions cache poisoning in release workflows

The attack chain begins when an attacker triggers a workflow path that can influence later release execution. By poisoning the GitHub Actions cache with a malicious pnpm store, the attacker primes the legitimate release pipeline to restore attacker-controlled content during a trusted run. This is a supply chain identity problem, not just a code integrity problem, because the workflow itself becomes the delivery vehicle for unauthorised execution.

Practical implication: separate untrusted pull request paths from release workflows and treat cache contents as security-sensitive build inputs.

OIDC token theft from runner memory

The payload extracts OIDC tokens directly from GitHub Actions runner process memory via /proc//mem. That matters because the attacker does not need long-lived static credentials if it can steal short-lived federated tokens during execution. The result is a high-trust, low-persistence compromise mode where temporary credentials are enough to publish malicious packages with valid provenance attestations.

Practical implication: harden runner isolation and memory exposure paths so ephemeral federation tokens are not recoverable during build execution.

Worm-like propagation through package lifecycle hooks

Once installed, the malicious package runs through npm lifecycle hooks and harvests GitHub, npm, cloud, and vault credentials from the host. It then identifies packages the victim can publish to, injects the same dependency pattern, bumps versions, and republishes compromised releases. This is why the attack behaves like a credential worm: each new compromised developer or runner expands the blast radius through delegated publishing rights.

Practical implication: reduce publish rights, inspect lifecycle hook execution, and assume package install paths can become credential collection points.

Threat narrative

Attacker objective: The attacker aims to turn trusted software delivery identities into a self-propagating credential theft and package distribution system.

1. Entry occurs through a poisoned GitHub Actions cache restored during a legitimate release workflow after an attacker-controlled pull request primes the pipeline.
2. Credential access happens when malicious code extracts OIDC tokens from runner memory and later steals npm, GitHub, cloud, Kubernetes, and vault credentials during package installation.
3. Escalation and impact follow as stolen publishing rights are used to republish compromised package versions, which then spread the worm across additional developer and CI environments while a destructive daemon threatens local data.

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

Trusted workflow identity is the new supply chain attack surface. This compromise worked because GitHub Actions, package publishing, and federated tokens were treated as separate layers when they were actually one delegated trust chain. OWASP-NHI and NIST-CSF both point to the same conclusion: if a build runner can mint, steal, or reuse publishing credentials, it is already an identity node with blast-radius potential. Practitioners should stop viewing CI as a neutral execution plane and treat it as a privileged identity domain.

Provenance is necessary, but it is not a safety boundary when the signing identity is already compromised. The malicious packages carried valid npm provenance attestations because they were published from within a legitimate runner using valid OIDC tokens. That means the control failed at the identity layer, not the package registry layer, and the failure mode is trusted attestation under attacker-influenced execution. The practical lesson is that provenance checks cannot compensate for a compromised publishing identity.

Ephemeral tokens do not eliminate abuse when runtime memory is exposed. The attacker did not need long-lived credentials because the runner itself became the secret source. This is a strong example of ephemeral credential trust debt, where short-lived access still creates exploitable windows if memory, logs, and workflow state are reachable. The implication is that identity assurance must include runtime containment, not just token expiry.

Mini Shai-Hulud shows how standing publish privilege becomes a propagation engine. Once stolen credentials reached accounts with package publish access, the attacker could inject the same payload into new releases and continue the chain. That makes package publishing rights a high-risk non-human identity function, especially when coupled to cloud and vault access. Practitioners should treat every publishable package namespace as a controlled identity perimeter.

Credential worms collapse the line between software supply chain and NHI governance. This is not only a developer compromise story. It is also a governance problem for GitHub tokens, npm tokens, cloud keys, and service account tokens that are valid across multiple systems and repositories. The field should expect more attacks that combine code execution, secret theft, and automated republishing into one loop, which means identity control planes need to span build, release, and runtime telemetry.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• For a wider view of how package and workflow compromise turns into identity exposure, see 52 NHI Breaches Analysis.

What this signals

Ephemeral credentials are not low-risk credentials when the runtime can be inspected. The attack shows that short-lived tokens become durable attack assets if the runner, cache, or workflow state can be read during execution. That is why build systems now need identity-grade monitoring, not only pipeline integrity checks.

Credential worm behaviour is collapsing the old boundary between software supply chain and identity governance. The next control discussion will be about which identities are allowed to publish, republish, and inherit trust across ecosystems. Teams that still map these problems only to DevSecOps will miss the access-review and offboarding failures that make propagation possible.

With 28% of secrets incidents now originating outside code repositories, the governance gap is moving into collaboration systems, ticketing tools, and CI metadata. Practitioners should expect more hidden exposure paths and should align detection with the places credentials actually move, not only where code is stored.

For practitioners

• Split trusted release workflows from untrusted pull request paths Prevent pull_request_target and similar high-trust workflow triggers from sharing caches, artifacts, or credentials with release jobs. Review where untrusted code can influence later publishing steps, especially in GitHub Actions and other CI runners.
• Treat runner memory and logs as secret-bearing surfaces Harden CI runners so OIDC tokens, npm credentials, cloud keys, and vault tokens are not recoverable from process memory, debug output, or persisted workspace files. Use ephemeral runners with minimal local state and strict process isolation.
• Reduce package publish rights to the smallest viable set Inventory every account that can publish or update packages, then remove broad access and separate build execution from release authority. Assume a compromised developer workstation or runner can laterally move through any namespace that still has standing publish permission.
• Search for persistence artifacts before revoking tokens Check for gh-token-monitor persistence files, install hooks, and payloads in .claude/ and .vscode/ directories before rotating credentials. Revoking tokens first can trigger destructive behaviour on infected hosts if the wiper is still present.

Key takeaways

• Mini Shai-Hulud shows that trusted build identities can be turned into a self-propagating credential worm.
• The scale matters: 373 malicious package-version entries across 169 npm package names and 2 PyPI packages were affected.
• The limiting control is not just scanning packages, but separating release authority from untrusted workflow paths and hardening runner runtime access.

Key terms

• Build Identity: A build identity is the non-human identity used by CI systems, runners, and release workflows to access repositories, tokens, package registries, and cloud services. It should be treated like any other privileged account because it can read, sign, publish, and distribute software at scale.
• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
• Credential Worm: A credential worm is malware that steals usable secrets from one system and then uses those secrets to spread into others. In supply chain environments, it often combines package install execution, publish rights, and automated republishing to create repeated compromise.
• 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.

Deepen your knowledge

Package supply chain compromise and credential propagation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around CI runners, package publishing, and ephemeral tokens, it is worth exploring.

This post draws on content published by Orca Security: Mini Shai-Hulud supply chain compromise and credential worm behavior. Read the original.