Mini Shai-Hulud shows signed supply chains can still be poisoned

At a glance

What this is: This analysis explains how Mini Shai-Hulud abused trusted CI, valid attestations and stolen credentials to publish poisoned packages through legitimate release pipelines.

Why it matters: It matters because IAM, CI/CD and NHI governance cannot stop at signatures and provenance when the publishing pipeline, OIDC token and runtime environment are all part of the attack surface.

By the numbers:

• Mini Shai-Hulud compromised 42 packages and 84 versions across the npm ecosystem.
• The TanStack compromise carries CVE-2026-45321 with a CVSS score of 9.6.

Context

Supply chain security breaks down when trust in the build system becomes a substitute for trust in the artifact. Signed provenance, attestations and registry controls all assume the pipeline that produced the package is still honest, but this attack shows that assumption can fail inside the release process itself.

The identity angle is direct: the compromise used GitHub Actions, OIDC tokens, package publishing rights and stolen developer credentials to move from build execution to downstream package abuse. That makes this more than a software integrity story, because the governing question is who or what is allowed to publish, attest and execute trusted code.

The starting position is increasingly typical for modern software teams, which is why the lesson lands so hard. Many organisations rely on CI trust, package signatures and secrets stored across developer tooling, while attackers are now targeting those same trust paths.

Key questions

Q: What fails when a supply chain attack reaches the build pipeline itself?

A: When an attacker compromises the CI system, provenance and signing can still be valid even though the artifact is malicious. The failure is not just weak attestation, but misplaced trust in the same environment that produced the package. Security teams need a separate verification layer that does not depend on the compromised build path.

Q: Why does a valid SLSA attestation not mean a package is safe?

A: A valid attestation can prove where the package came from and how it was built, but not whether the artifact contains malicious code or unsafe behaviour. If the attacker controlled the pipeline, the attestation may be accurate and still dangerous. Practitioners should pair provenance with independent content analysis and downstream policy enforcement.

Q: How do supply chain worms turn one compromised package into broader identity risk?

A: They steal publishing tokens, developer secrets and workflow credentials, then use those identities to move into other packages, environments and tools. The risk expands because the compromise crosses build systems, developer machines and registry access. Teams should govern publishing credentials and developer secrets as a single identity surface.

Q: Should teams verify packages again at runtime instead of only in CI?

A: Yes. Build-time checks stop at the pipeline, but many malicious payloads execute only when imported or run in production, a laptop or an edge environment. Rechecking signatures, scan attestations and policy approvals at point of use gives you a second control plane that can block unsafe execution even if the pipeline was compromised.

Technical breakdown

How the attack entered the release pipeline

The initial foothold came through the CI system, not through a compromised package registry. The attackers used pull_request_target and GitHub Actions cache poisoning to execute code inside the legitimate TanStack environment, which is a classic example of trusted automation being turned into an execution layer. Once code runs in a privileged runner, the attacker is no longer limited to the repository contents. They can inspect process memory, inherited environment variables and workflow context. In this case, the release pipeline itself became the bridge from malicious input to trusted output, because the build environment was treated as inherently safe even though it was being driven by untrusted content. See the CI/CD Pipeline Identity Security Guide.

Practical implication: Treat CI runners, workflow triggers and cache reuse as attack surfaces that need hard segmentation, not just build convenience.

Why valid attestations did not stop poisoned artifacts

SLSA provenance proves where and how an artifact was built, but it does not prove the artifact is benign. That distinction matters here because the attacker used the trusted release workflow to generate valid Level 3 provenance for a malicious package. The attestation was accurate about the build environment and process, yet still useless as a safety guarantee because the attacker had already manipulated the build inputs and output. This is the core limitation of provenance-only thinking: integrity metadata can be correct while the object it describes is still hostile. A trusted chain of custody is not the same as a safe artifact. See the Malicious Package and Dependency Confusion Guide.

Practical implication: Attach artifact safety checks to the package itself, not just to the provenance trail around it.

How the payload turned published packages into a credential theft loop

The malicious router_init.js payload did more than steal one secret. It searched for cloud provider credentials, wallet material, AI tool credentials, messaging tokens and CI secrets, then persisted inside developer tooling and watched for newly exposed tokens. That created a self-reinforcing theft loop where every new credential increased the worm's reach. The later stages also abused GitHub tokens, OIDC exchange and maintainer publishing rights to repeat the compromise across packages. The important architectural point is that package compromise, identity theft and workflow abuse formed one chain, so controls limited to package scanning alone would miss the operational blast radius. See the SaaS-to-SaaS and OAuth App Governance Guide.

Practical implication: Monitor for credential harvesting, token reuse and workflow tampering as one incident class rather than three separate problems.

Threat narrative

Attacker objective: The attacker wanted to turn trusted package publishing and developer tooling into a repeatable secret-harvesting and malware distribution channel.

1. Entry began when attackers staged a malicious payload in a GitHub fork and triggered execution inside the legitimate CI environment through pull_request_target and cache poisoning.
2. Credential access followed when the runner's process memory exposed an OIDC token and the payload harvested cloud, AI, messaging and CI secrets from the environment.
3. Escalation and replication occurred when the worm used publishing tokens, maintainer package access and GitHub OIDC exchange to issue further malicious releases with valid attestations.
4. Impact was a supply chain worm that propagated poisoned packages, exfiltrated secrets and established persistence across developer tooling and release workflows.

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.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

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

Provenance is not safety: the most dangerous assumption in this incident is that valid SLSA attestations could substitute for artifact trust. They cannot, because provenance describes the build path, not the maliciousness of the output. Once an attacker owns the pipeline, a correct attestation can become a high-confidence wrapper around a poisoned package. Practitioners should separate build integrity from artifact safety and treat both as distinct governance problems.

CI trust boundaries are now identity boundaries: GitHub Actions, OIDC federation and publishing tokens are not just developer conveniences, they are non-human identities with powerful release authority. CI/CD pipeline identity security matters here because the compromise moved through workflow trust, not just code trust. If a runner can mint or retrieve publish credentials, then build-time controls are already inside the blast radius.

Runtime containment is the missing second control plane: the worm succeeded because detection and enforcement were too close to the build event and too far from execution. Policy has to live outside the pipeline, and enforcement has to reoccur when the artifact actually runs. That is the right mental model for modern supply chain governance: verify the artifact, then verify it again where it is used.

Secrets sprawl created the worm's multiplier effect: the payload was able to move from one compromised package to other tools because organisations still co-locate npm, PyPI and developer credentials in ways that make lateral token abuse trivial. That is a non-human identity governance failure as much as a software supply chain failure. The lesson is to treat package credentials, publishing rights and runtime tokens as a governed estate, not as incidental developer state.

Mini Shai-Hulud is a supply chain identity compromise, not just a malware event: the attacker used trusted automation, federated identity and maintainer privileges to turn signing into camouflage. That is why the relevant control conversation belongs with identity lifecycle, publishing authority and workflow governance, not with signatures alone. The practitioner takeaway is to manage release identity as aggressively as production access.

From our research library:

• 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: AI Supply Chain Security and AI-BOM Guide

What this signals

Policy must move out of the pipeline: if the same system both produces and approves an artifact, an attacker only has to win one trust boundary. The practical response is to treat verification, policy and execution as separate controls, with local enforcement at the moment the package runs rather than only when it is built. That architecture becomes more urgent as attackers learn to weaponise legitimate release workflows.

Third-party exposure is now part of supply chain governance: 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs. The implication is that package publishing, registry access and developer automation should be treated as shared identity territory, not as isolated engineering concerns.

For practitioners

• Separate build trust from artifact trust Require independent verification of artifact content, scan results and policy approval outside the CI system that produced the package. Do not let the same pipeline both create and bless the release.
• Harden GitHub Actions release paths Review pull_request_target usage, cache poisoning exposure, runner permissions and publish-time token handling. Reduce the ability for untrusted input to reach privileged release steps.
• Scope and rotate publishing identities Treat npm, PyPI and similar publishing tokens as high-risk non-human identities with narrow scope, short lifespan and explicit offboarding. Revoke any token that can mint or publish multiple packages from one maintainer context.
• Quarantine artifacts before execution Add point-of-use verification in developer endpoints, cloud runtimes and edge environments so signature checks, scan attestations and policy approvals are re-evaluated at execution time.
• Contain blast radius with runtime controls Use sandboxing, egress restriction, tool-level permissions and tamper-evident logging so a compromised package cannot freely exfiltrate secrets or persist inside developer tooling.

Key takeaways

• Mini Shai-Hulud shows that supply chain compromise can travel through legitimate CI, valid signatures and trusted release workflows at the same time.
• The incident exposed a control gap where provenance proved build history but not artifact safety, while the payload harvested credentials and spread through maintainer identities.
• Independent verification outside the pipeline, point-of-use checks and tighter publishing identity governance are the controls that would have limited the blast radius.

Related NHI Mgmt Group resources: CI/CD Pipeline Identity Security Guide · SaaS-to-SaaS and OAuth App Governance Guide · Malicious Package and Dependency Confusion Guide · Shai-Hulud npm worm first wave 2025

Key terms

• Artifact Attestation: Evidence that a build output was produced by a trusted process and has not been altered before execution. It is a practical control for software and AI supply chains because it helps separate approved runtime inputs from files that merely look legitimate.
• Point-of-Use Verification: Point-of-use verification is a second check performed where software or AI artifacts actually run, rather than only where they are built. It reduces the chance that a compromised pipeline can smuggle unsafe output past build-time controls and into execution.
• Release-Pipeline Identity: The credentials, tokens, and service accounts that allow software to be built, signed, published, or deployed. These identities are high-value because compromise can turn a local developer or CI event into access to registries, cloud environments, and downstream customers.
• Runtime containment: A control approach that limits harmful behaviour while an AI agent is still active rather than waiting for post-incident review. It depends on signals such as anomalous tool use, privilege expansion, or unusual data access so security teams can intervene before blast radius grows.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps practitioners connect identity controls to software supply chain and runtime governance decisions.