Mini shai-hulud shows how npm supply chain worms spread

At a glance

What this is: This is a supply chain worm analysis showing how compromised npm packages were published through CI/CD and then used to steal secrets, persist, and spread further.

Why it matters: It matters because identity, secrets, and build provenance controls are now part of the same blast radius, so IAM, PAM, and NHI teams must govern pipeline-issued credentials as production access.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.

👉 Read StepSecurity’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 release paths into a propagation mechanism. In this case, the malware used compromised GitHub Actions workflows, hijacked OIDC tokens, and stolen CI/CD secrets to publish malicious npm packages while also harvesting credentials from developer and runner environments.

The identity angle is direct: build pipelines, workload tokens, and secret stores are functioning as non-human identities with real privilege, yet they are often governed as temporary tooling rather than access-bearing assets. That gap makes package signing, secret handling, and pipeline isolation inseparable from identity governance, especially when the payload can move from a single runner to many downstream packages.

The starting position here is not unusual for modern supply chain intrusions, but the worm-like propagation and valid provenance attestations make the failure mode more severe than a routine package compromise.

Key questions

Q: What breaks when a CI/CD workflow can publish packages and access secrets at the same time?

A: A single workflow compromise can become a full trust collapse. If the same pipeline can read secrets, mint tokens, sign artifacts, and publish releases, an attacker only needs one foothold to spread malicious packages and harvest downstream credentials. Separation of duties, least privilege, and short-lived credentials are what stop that shortcut.

Q: Why do CI/CD pipelines make secret theft easier for attackers?

A: Pipelines often concentrate cloud keys, package tokens, environment variables, and deployment credentials in one execution path. That concentration gives attackers a single place to harvest multiple NHI types at once. When the pipeline is trusted to run automatically, any malicious workflow update can turn that trust into credential exposure.

Q: How should security teams govern OIDC and workload tokens in release pipelines?

A: Treat OIDC and other workload tokens as privileged identities with explicit audience, repository, and job restrictions. Do not grant broad federation by default. Pair token scoping with workload segregation, so a compromised job cannot reuse its identity to publish code, access cloud services, or move into adjacent pipelines.

Q: Who is accountable when a compromised pipeline publishes malicious packages?

A: Accountability usually sits with the organisation that issued the publishing credential, maintained the pipeline trust boundary, and failed to constrain release authority. In practice, this is an IAM, DevSecOps, and platform governance issue together, not a developer-only mistake.

Technical breakdown

How a pull_request_target workflow becomes a release-path compromise

The attack chain begins with GitHub Actions trust abuse. A pull_request_target workflow runs with elevated repository context, which can expose secrets, tokens, or cache artifacts if the workflow is not tightly constrained. By poisoning cache state and extracting OIDC material from runner memory, the attacker moved from code execution in the pipeline to the ability to publish packages through the project’s own release process. In practical terms, the workflow itself became the trust boundary failure, not just the malware payload.

Practical implication: restrict pull_request_target usage, isolate release jobs, and treat runner-issued OIDC tokens as privileged credentials with narrow scope.

Why secret harvesting from runners scales so quickly

CI/CD runners are dense credential environments. They often contain cloud tokens, npm credentials, GitHub tokens, AI tool settings, and service access files in memory or on disk. A worm that can enumerate runner process memory and common credential paths does not need a single bespoke secret to succeed. It can exfiltrate many identity types at once, which is why secret discovery, masking, and revocation must be coupled with workload isolation and egress controls.

Practical implication: inventory every secret class reachable from runners and enforce short-lived credentials plus immediate revocation on compromise.

How valid provenance can still accompany malicious code

SLSA provenance tells you something about how a build was produced, but it does not by itself prove the build was safe. If an attacker controls the release pipeline or injects malicious logic before attestation is generated, the package can carry valid provenance while still being harmful. That is a critical distinction for software supply chain governance: integrity of the process is not the same as trustworthiness of the output when the pipeline identity itself is compromised.

Practical implication: validate both provenance and pipeline identity controls, then add policy checks that fail closed on suspicious release behaviour.

Threat narrative

Attacker objective: The attacker’s objective was to use one compromised build environment to harvest secrets, publish infected packages, and expand compromise across the maintainer’s package portfolio.

1. Entry occurred through a compromised pull_request_target workflow and poisoned CI/CD state that allowed malicious code to run in the release path.
2. Credential access followed when the payload extracted OIDC tokens, GitHub runner secrets, and other local credentials from memory and common file locations.
3. Impact came from self-propagation and malicious package publication, turning the compromised maintainer environment into a worm that spread across additional npm packages.

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

Pipeline credentials are now non-human identities, not temporary implementation details. The worm succeeds because CI/CD tokens, runner secrets, and OIDC credentials are treated as disposable build artifacts rather than governed identities. Once those tokens can publish software, they become production access. For identity teams, that means release pipelines need lifecycle control, least privilege, and monitoring equivalent to any other privileged service account.

Secret sprawl creates worm-friendly conditions even before the first package is published. The payload’s ability to harvest cloud, AI, developer, and messaging credentials shows that the blast radius of a compromised runner extends well beyond source control. This is the same governance failure the OWASP NHI Top 10 warns about: broad credential reach with weak segmentation. Practitioners should treat every runner environment as a high-value identity container.

Valid provenance does not neutralise a compromised release identity. The most important lesson here is that attestation alone cannot compensate for a tainted build path. A malicious package can still carry valid SLSA attestations if the attestation was produced inside a compromised trust boundary. That shifts the control question from provenance alone to the security of the publishing identity and the surrounding pipeline policy.

Supply chain defense now depends on runtime containment as much as pre-release review. This worm spreads after code has entered the delivery system, which means blocked merges alone are not enough. Egress restrictions, runner isolation, package cooldowns, and automated secret revocation all become part of identity governance for software delivery. Teams should reframe CI/CD from a DevOps convenience to a privileged identity plane.

Mini Shai-Hulud is a named example of release-path identity collapse. The concept captures what happens when the same identity can build, sign, publish, and exfiltrate. That concentration of privilege is what enables a single compromise to become ecosystem-wide propagation. The practical conclusion is to separate build, attest, and publish authorities before a worm finds that shortcut for you.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, 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, according to The State of Secrets Sprawl 2026.
• Forward-looking control work should shift from leak detection to exposure shortening, and 52 NHI Breaches Analysis shows how compromised identities turn into repeatable attack paths.

What this signals

Supply chain worms now intersect directly with identity governance because release pipelines behave like privileged service identities. Teams that still separate “developer tooling” from “real access” will miss the fact that OIDC federation, runner secrets, and package publish rights can all be abused as one chain. The practical shift is to govern pipelines as access-bearing assets, not ephemeral build machinery.

Release-path identity collapse: when one workflow can authenticate, attest, and publish, attackers inherit a complete trust shortcut. That pattern will keep surfacing until organisations separate duties across build, sign, and release systems, and until they enforce egress containment on runners with tools such as MITRE ATT&CK Enterprise Matrix.

For identity programmes, the next question is not whether secrets will leak but how quickly they can be revoked after a compromise. That pushes teams toward stronger lifecycle controls, better blast-radius segmentation, and tighter linkage between CI/CD telemetry and incident response playbooks.

For practitioners

• Restrict release-path workflow privileges Remove broad trust from pull_request_target and split build, test, and publish into separate workflows with narrowly scoped permissions and environment approvals.
• Treat runner-issued OIDC tokens as production credentials Scope OIDC federation to specific repositories, jobs, and audiences, then rotate or revoke tokens immediately when a workflow compromise is suspected.
• Isolate and monitor CI/CD egress Apply outbound allowlisting to runners so a compromised job cannot reach arbitrary C2 domains or exfiltration endpoints before containment triggers.
• Automate secret revocation after pipeline compromise Build response playbooks that invalidate cloud keys, npm tokens, GitHub tokens, and other exposed secrets as soon as a malicious workflow is confirmed.
• Separate attest, sign, and publish authorities Do not let one compromise path create both release credentials and provenance artifacts; keep signing keys and publish permissions under distinct controls.

Key takeaways

• Mini Shai-Hulud shows that a compromised release pipeline can function as a self-spreading supply chain worm, not just a one-off malware event.
• The incident matters because CI/CD secrets, OIDC tokens, and provenance artifacts were all part of the same trust boundary, which multiplied the blast radius.
• The limiting controls are separation of duties, runner isolation, egress restriction, and immediate secret revocation when a publish path is abused.

Key terms

• Pull_request_target workflow: A GitHub Actions trigger that runs in the context of the base repository, not the contributor’s fork. That means it can access repository secrets while processing untrusted pull request content, which creates a sharp trust boundary and a common route to secret theft if not carefully segmented.
• OpenID Connect Token: An OpenID Connect token is a machine-readable credential used to convey identity claims in an OAuth 2.0 based flow. It is typically lighter than a SAML assertion and fits modern applications well, but it demands strong issuer, audience, and expiration checks to avoid token misuse.
• 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.
• Release-path identity: The set of identities, tokens, permissions, and approvals that allow code to move from build to signed artifact to published package. When this identity chain is overly broad, an attacker can hijack the same path used for trusted delivery and turn it into a distribution channel.

What's in the full article

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

• A runtime packet-and-process view of the compromised GitHub Actions workflow, including the network telemetry and process tree used to confirm the worm.
• The full list of affected npm packages and versions, which teams need for triage, dependency review, and incident scoping.
• Details of the payload’s secret-harvesting, persistence, and exfiltration logic across runners, local developer devices, and package publishing workflows.
• The remediation and detection guidance tied to StepSecurity tools, including cooldown checks, malicious package blocking, and registry controls.

👉 The full StepSecurity post covers the compromised package list, runtime evidence, and remediation workflow in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to control privileged non-human access. It helps security leaders connect identity lifecycle discipline to the controls that reduce blast radius across pipelines and production systems.