Mini Shai-Hulud exposes weak trust boundaries in npm workflows

At a glance

What this is: This is an analysis of the Mini Shai-Hulud NPM supply chain worm and how it moved from compromised workflows into package publishing.

Why it matters: It matters because NHI, IAM, and platform teams have to govern ephemeral credentials, CI/CD trust, and package publishing rights as one control surface, not separate problems.

By the numbers:

• The Mini Shai-Hulud campaign compromised over 169 package names and created more than 400 malicious package version entries.
• Packages like @tanstack/react-router account for over 12 million weekly downloads.

👉 Read ArmorCode's analysis of the Mini Shai-Hulud npm supply chain worm

Context

Mini Shai-Hulud is a supply chain worm that turns trusted build and publish paths into propagation channels. In practical terms, the problem is not just secret theft, but the misuse of runtime credentials, OIDC federation, and package lifecycle hooks inside CI/CD.

For IAM and NHI programmes, this is a governance problem as much as a malware problem. Ephemeral tokens, service identities, and publish permissions are often managed in different tools, yet the attack chain spans all of them; that fragmented ownership is typical, not exceptional.

Key questions

Q: What breaks when NPM supply chain worms can run inside privileged CI workflows?

A: The trust boundary between code review and code execution breaks down. A malicious change can inherit the workflow’s publish permissions, mint federation tokens, and turn a build identity into a distribution path. That is why CI runners and release workflows need least privilege, explicit separation, and logging that ties each publish action to a verified human or service owner.

Q: Why do non-human credentials amplify supply chain risk in developer pipelines?

A: Because they are reusable across systems, often over-scoped, and frequently minted in automation contexts that are assumed safe. When a runner, token, or service account is compromised, the attacker can move from one system to many without additional user interaction. The risk rises sharply when rotation, revocation, and workload identity ownership are fragmented.

Q: How do teams know if agentic CI/CD controls are actually working?

A: Look for evidence that the agent cannot reach secrets, cannot mutate protected branches, and cannot execute shell commands outside its declared boundary. If telemetry shows attempted outbound calls, credential access, or policy violations being blocked or alerted on, the control is operating. If you only see clean workflow files, you do not yet know whether runtime guardrails are effective.

Q: Who is accountable when a poisoned package reaches production through approved dependencies?

A: Accountability usually sits with both the platform team that owns package policy and the application owners who accepted the exception. Once a package is allowed to execute, it becomes a governed privilege decision. That means approvals, publisher identity checks, and revocation procedures need ownership just like any other elevated access path.

Technical breakdown

How GitHub Actions trust boundaries were abused

The worm did not need a stolen maintainer password. It exploited the pull_request_target pattern, poisoned the GitHub Actions cache across the fork-to-base boundary, and used attacker-controlled code inside a privileged workflow context. From there, it extracted an OIDC token at runtime and converted that identity assertion into valid publishing access. The key mechanism is trust transitivity: once a workflow can mint tokens and invoke external actions, an attacker who reaches code execution can pivot from build context to supply chain distribution.

Practical implication: separate untrusted pull request execution from privileged publish workflows and constrain OIDC federation scopes.

Why lifecycle hooks and Git-based dependencies amplify propagation

Mini Shai-Hulud embedded itself through optionalDependencies pointing to a malicious GitHub-hosted commit, then relied on NPM prepare lifecycle hooks to execute during install. That matters because package installation is treated as a routine trust event, but Git-based dependencies can run code before defenders expect it. The worm also persisted in developer and tooling files such as .claude/settings.json and .vscode/tasks.json, so removing one package does not remove the infection path. This is a classic example of runtime persistence plus supply chain auto-execution.

Practical implication: restrict Git-based dependencies, disable unnecessary install-time scripts, and monitor workspace files for persistence artefacts.

How secrets harvesting turned one foothold into broad credential reuse

Once active, the payload swept GitHub Actions tokens, AWS credentials, Vault tokens, Kubernetes service account tokens, and repository secrets. That is not broad opportunism, but a deliberate identity-collection phase designed to find any reusable credential that can extend reach. The campaign then used stolen credentials to publish new malicious package versions, proving that credential scope and token lifetime directly shape blast radius. In identity terms, the worm abused non-human identities as both the entry mechanism and the propagation mechanism.

Practical implication: treat CI runners, service accounts, and federation tokens as high-value identities with revocation and rotation playbooks.

Threat narrative

Attacker objective: The attacker objective was to turn one compromised workflow into a self-replicating package-publishing channel that steals credentials and spreads through trusted developer ecosystems.

1. Entry began with a compromised GitHub Actions workflow path, where attacker-controlled code was executed in a privileged pull_request_target context.
2. Credential access followed as the payload harvested OIDC tokens, GitHub Actions tokens, AWS credentials, Vault tokens, Kubernetes service account tokens, and repository secrets.
3. Escalation and propagation occurred when the stolen OIDC token was exchanged for NPM publish access, allowing the worm to inject itself into additional packages.
4. Impact was supply chain amplification, with poisoned packages distributed through trusted NPM install flows and secrets exfiltrated through a covert network channel.

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

Supply chain worms are now identity abuse problems, not just malware problems. Mini Shai-Hulud succeeds because it converts build identities, publish identities, and workload secrets into propagation fuel. That means the relevant control plane is IAM and NHI governance, not only artifact scanning. Teams that still treat CI/CD tokens as low-friction utility credentials are managing the wrong risk class. Practitioner conclusion: govern build and publish identities as production-grade assets.

Ephemeral credentials do not help if the runtime that mints them is trusted too broadly. The attack shows how OIDC federation, runner context, and workflow permissions can be chained into a valid publish action without stealing a long-lived token. That creates a named failure mode we can call workflow trust transitivity: a privileged automation path inherits trust from every upstream step until one malicious code path breaks the chain. Practitioner conclusion: constrain token minting at the workflow level, not just at the secret level.

Lifecycle hooks are a hidden execution layer in NPM governance. Package install is often reviewed as a dependency event, but prepare hooks, Git-based dependencies, and workspace persistence files create an execution surface that behaves like code deployment. This is where software supply chain security and identity governance intersect, because the actor that installs the package is also the identity that can be tricked into executing it. Practitioner conclusion: treat install-time execution as part of identity risk review.

Credential revocation latency is the difference between detection and containment. The campaign explicitly harvested multiple token types and warned teams to rotate NPM tokens, GitHub PATs, OIDC federation grants, AWS credentials, Vault tokens, and Kubernetes service account tokens immediately. That is a reminder that valid credentials remain exploitable long after initial discovery if revocation is not automated and scoped. Practitioner conclusion: build revocation into incident response, not as a post-incident cleanup task.

Provenance badges are not a substitute for trust validation. A package published with a provenance attestation can still be malicious if the workflow that generated it was compromised. This matters for the broader agentic AI and NHI landscape because machine identities are increasingly used to assert legitimacy across pipelines and toolchains. Practitioner conclusion: verify the identity of the publisher workflow, not just the existence of provenance metadata.

From our research:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• From our research: 28,65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase, according to The State of Secrets Sprawl 2026.

What this signals

Workflow trust transitivity: security teams should treat every privileged automation path as a chain of delegated identities, not a single control point. Once a pull request can influence a publish job, identity assurance, script execution, and provenance all need to be evaluated together. OWASP's OWASP Non-Human Identity Top 10 is directly relevant here.

The practical signal is that revocation must become operational, not advisory. When runners, service accounts, and federation tokens are harvested in the same incident, the response window is measured in minutes of containment and hours of credential invalidation, not days of investigation.

Supply chain resilience now depends on identity-aware dependency policy. If your programme can describe package risk but not who can mint, publish, and re-execute credentials, then the control model is incomplete. The next step is to connect CI/CD policy to machine identity governance and release authorisation.

For practitioners

• Segment privileged workflow identities Separate untrusted pull request execution from repository workflows that can mint OIDC tokens or publish packages. Require explicit approval gates for any job that can access release credentials or federation grants.
• Block install-time execution paths Disable or tightly control NPM scripts, Git-based dependencies, and prepare hooks in build environments. Add policy checks for optionalDependencies that reference GitHub commits or other executable sources.
• Inventory and rotate exposed non-human credentials Maintain a response runbook for GitHub PATs, AWS credentials, Vault tokens, Kubernetes service account tokens, and NPM tokens. Use short-lived federation where possible and revoke tokens from CI runners as soon as compromise is suspected.
• Watch for persistence in developer tooling files Scan .claude/settings.json, .vscode/tasks.json, and similar workspace files for unauthorized entries that can re-execute payloads. Treat developer workstation artefacts as part of the incident scope, not a separate cleanup task.

Key takeaways

• Mini Shai-Hulud shows that NPM supply chain attacks are now identity and workflow abuse problems, not only malicious-package problems.
• The campaign combined privileged workflow access, credential harvesting, and install-time persistence to create a repeatable propagation model across packages and runners.
• Teams need tighter publish-path isolation, faster token revocation, and explicit governance for CI/CD non-human identities before the next worm arrives.

Key terms

• Workflow Trust: Workflow trust is the confidence users place in a familiar business process, such as document signing or payment approval. Attackers exploit that confidence by imitating normal requests, so the control failure is often the process itself rather than the technology used to deliver it.
• Prepare Lifecycle Hook: An install-time script that runs automatically when an NPM package is prepared or installed from a Git source. It is powerful because it executes before many defenders expect code to run, turning dependency resolution into an execution surface if the source is malicious or compromised.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• OIDC Federation: OIDC federation is a token-based trust model that lets one system accept identity assertions from another. It is commonly used to avoid static cross-environment credentials and to issue short-lived access based on trusted token claims. The control value depends on how tightly the trust relationships are governed.

What's in the full article

ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step detection workflow for identifying affected packages, runners, and saved views across connected scanners.
• Exact indicators of compromise for router_init.js, tanstack_runner.js, and the malicious orphaned commit SHA-256 values.
• Guidance on using Anya, Findings, and SBOM saved views to triage impacted applications and components.
• The companion guide path for long-term NPM supply chain defenses, including lockfile enforcement and trusted publishing.

👉 ArmorCode's full post covers the affected packages, indicators of compromise, and response workflow details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps security practitioners translate identity controls into operational resilience across pipelines, services, and release processes.