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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Orca Security's research: Mini Shai-Hulud turned trusted npm release paths into a credential-stealing worm that propagated through maintainer workflows and infected packages.

Why it matters: It matters because IAM and NHI teams must treat CI tokens, package provenance and workflow trust as governable identity surfaces, not just build hygiene.

Context

Mini Shai-Hulud is a software supply chain attack, but the core governance problem is identity trust in build and release systems. The exploit path depends on legitimate workflows, short-lived credentials, and package publishing privileges that can be abused without a long-lived secret.

For IAM and NHI programmes, this is a reminder that CI runners, OIDC exchanges, npm tokens, cloud metadata credentials and service account tokens form one identity chain. When that chain is trusted end to end, a malicious package can become both the payload and the propagation mechanism.

Key questions

Q: What breaks when a package supply chain can mint valid publish credentials from inside a trusted workflow?

A: What breaks is the assumption that build-time trust can be inferred from provenance alone. If an attacker can influence the runner that creates or signs the package, the resulting artefact may be authentic in form but malicious in origin. Security teams need to govern workflow integrity and token issuance as part of the trust boundary, not after the fact.

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 are the warning signs that an npm package worm is already spreading through an organisation?

A: Look for unexpected package version bumps, new publish activity from maintainer identities that do not match normal release patterns, unusual token use in CI logs, and persistence artefacts on developer endpoints. A worm will also leave traces in lockfiles, lifecycle hooks and credentials that appear in more than one environment.

Q: How should teams respond when a package publication workflow is compromised?

A: Contain the environments that installed the affected versions, then rotate any credentials those environments could access from a clean system. Rebuild from a known-good lockfile, invalidate active sessions, and review logs for publication events, GitHub API calls, cloud metadata access, and unexpected build artefacts.

Technical breakdown

GitHub Actions workflow abuse and token extraction

The initial compromise used a chain of GitHub Actions weaknesses: a fork, a pull request that triggered a pull_request_target workflow, and a poisoned cache that later fed the release job. The key detail is that the attacker did not need to steal a long-lived secret. Instead, the malicious code extracted OIDC tokens from runner memory, then used those valid tokens inside the legitimate build context to publish malicious package versions. That is a release-path compromise, not a simple credential theft event. Practical implication: treat workflow trust boundaries, cache reuse and token minting paths as part of the identity attack surface, not just the CI platform.

Practical implication: isolate release workflows from untrusted pull_request_target execution and restrict token scope to the minimum publishing path.

Why provenance can be a false safety signal

Package provenance normally helps show where an artefact came from, but this attack shows provenance is only as trustworthy as the execution context that signs or publishes the package. Because the malicious releases were produced from a legitimate runner with valid OIDC credentials, the resulting attestations still looked legitimate. That means provenance can confirm the workflow path, while failing to detect that the workflow itself was manipulated. In identity terms, the trusted signer became the compromised control plane. Practical implication: validate provenance alongside workflow integrity, runner isolation and package-namespace governance, not as a standalone trust decision.

Practical implication: verify the integrity of the build workflow and runner before trusting provenance or attestation metadata.

Credential worm propagation through npm lifecycle hooks

Once installed, the payload ran during npm lifecycle hooks and harvested GitHub tokens, npm tokens, cloud credentials, Kubernetes service account tokens, Vault tokens and environment variables. It then identified what the victim could publish, modified package archives to embed the same payload and republished new compromised versions. That is why the article calls it a worm: every infected developer workstation or CI runner becomes a new publishing identity. The attack does not rely on a single stolen secret. It converts publish permission into propagation permission. Practical implication: model package publishing rights as high-risk NHI privileges and separate them from everyday development access.

Practical implication: separate package-publishing identities from routine developer credentials and tightly scope what can publish to public registries.

Threat narrative

Attacker objective: The attacker objective is to steal valid credentials, spread malicious package releases through trusted build and publish channels, and preserve destructive leverage over affected developers and maintainers.

1. Entry occurred through a poisoned GitHub Actions path that combined a fork, a pull request and a compromised workflow cache.
2. Credential access followed when the payload extracted OIDC tokens and later harvested npm, cloud, Kubernetes and Vault credentials from infected systems.
3. Escalation and lateral movement happened as the malware used stolen publishing access to inject itself into additional package releases, turning each victim into a new infection source.
4. Impact was ecosystem-wide propagation of malicious npm and PyPI packages, plus a persistent wiper component that could destroy developer home directories if GitHub tokens were revoked.

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.
• GitHub internal repositories breach 2026: A stolen GitHub CLI token let attackers publish a poisoned Nx Console extension that harvested secrets and exfiltrated 3,800 GitHub repos.

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

Package provenance failed because the signer and the compromise lived inside the same trusted workflow: provenance can describe where a package came from, but not whether the release job was already poisoned. When an attacker can influence workflow execution and token minting at publish time, signed artefacts become evidence of trusted abuse, not evidence of safety. Practitioners should stop treating attestations as a standalone trust boundary.

Publish rights are now propagation rights: this campaign shows that package-publishing access is no longer a narrow release function. It is a replication mechanism that can turn one compromised maintainer context into many compromised namespaces. That changes the governance question from who can ship code to who can authoritatively mint identity for the software supply chain.

Workflow trust has to be governed as NHI trust: GitHub Actions runners, OIDC tokens, npm tokens and cloud metadata credentials all behave like machine identities with different lifetimes and scopes. If those identities are not inventoried, bounded and offboarded as a set, a single compromised workflow can bridge development, publishing and cloud access in one chain.

Ephemeral credential trust debt: short-lived tokens reduce reuse, but they do not eliminate abuse when the runtime that mints them is already compromised. The article shows that ephemeral credentials can still be weaponised at issuance time, so the governance assumption that shorter lifetime equals safer identity has to be re-examined.

Mini Shai-Hulud is a supply chain worm, not just a package malware event: the important shift is recursive propagation through trusted publisher identities. Once a malicious package can harvest credentials and republish itself, the control problem moves from malware detection to identity containment across the software delivery chain.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, 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: Top 10 NHI Issues

What this signals

Credentialised build trust is the weak point: supply chain teams should assume that OIDC, npm publishing tokens and cloud metadata credentials can be abused together when a runner is already compromised. The control boundary therefore shifts from secret storage to release-path governance.

Package publishing is an identity escalation path: once a maintainer context can republish poisoned artefacts, the blast radius expands beyond one repository into every namespace that trusts that maintainer. Security programmes need to treat publish access as a privileged identity with offboarding, not a convenience feature.

The figure that matters operationally is not just the package count but the propagation model: 92% of organisations expose NHIs to third parties, raising concerns about supply chain security according to the Ultimate Guide to NHIs. That exposure pattern is exactly why supply chain identity controls need to be lifecycle governed, not assumed safe because the credentials are short lived.

For practitioners

• Harden release workflows against untrusted triggers Separate pull request validation from release publishing, and block any path where untrusted code can influence a workflow that mints publish credentials or restores attacker-controlled cache state.
• Inventory and revoke impacted publishing identities Map every npm token, GitHub token, cloud credential, Kubernetes service account token and Vault token that could have been exposed on affected runners, then rotate or revoke them as a single incident set.
• Inspect runners for persistence and payload residue Check developer and CI environments for lingering files in .claude, .vscode, LaunchAgents and systemd user services, and remove any gh-token-monitor or package payload artefacts before re-enabling access.
• Validate package consumption against trust assumptions Treat provenance, attestation and signed release metadata as inputs to a broader trust decision, not proof that a package is safe to install or publish.
• Reduce namespace blast radius for package publishing Limit which identities can publish to each namespace, segregate maintainer accounts from everyday developer access, and review whether publish privilege is broader than the business need.

Key takeaways

• Mini Shai-Hulud turned trusted package publishing paths into a credential worm, which means release workflows now sit inside the identity attack surface.
• The compromise affected TanStack, Mistral AI, UiPath and more than 160 npm and PyPI packages, showing how quickly one poisoned publish path can scale.
• The decisive control is not just secret rotation. It is release-path isolation, publish privilege restriction and workflow integrity checking before tokens are minted.

Key terms

• 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.
• 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.
• Workflow trust boundary: A workflow trust boundary is the point where one step in a business or technical process stops being fully trusted and must be checked before the next step continues. It defines where identity, data, or action permissions change, and where controls such as approval, validation, logging, or isolation should be applied.
• Package Publishing Identity: The account, token, or workflow that authorises a software package release into a registry. In practice, this identity behaves like a privileged non-human identity because compromise lets an attacker publish trusted code to many downstream consumers.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.