Shai-Hulud npm worm v2 exposes the identity gaps in supply chains

At a glance

What this is: This is an analysis of Shai-Hulud v2, an npm supply chain worm that steals secrets, propagates through maintainer tokens, and adds GitHub Actions-based persistence.

Why it matters: It matters because package maintainers, platform teams, and IAM leads now have to govern npm tokens, cloud secrets, and runner credentials as one identity surface.

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 Semgrep's analysis of the Shai-Hulud npm worm v2

Context

Shai-Hulud v2 is a npm supply chain worm that turns package installation into secret theft, package propagation, and GitHub Actions persistence. The primary identity problem is not just malicious code in a dependency, but the way maintainer tokens, cloud credentials, and runner privileges are trusted as if they were separate control domains.

For IAM and NHI teams, the practical issue is lifecycle failure across the software supply chain. A stolen npm token can become publishing authority, a GitHub token can become workflow creation authority, and self-hosted runners can become persistence infrastructure if their identity and execution scope are not tightly bounded.

The article shows a typical modern compromise path: an infected package executes during install, collects secrets from files and environment variables, then uses legitimate tokens to spread further. That is a familiar pattern in NHI incidents, but the GitHub Actions persistence layer widens the blast radius into build and CI/CD governance.

Key questions

Q: What breaks when a malicious npm package can read developer secrets during install?

A: The main failure is that package execution inherits identity context it should never need. Once a malicious install can read environment variables, local files, and CI secrets, it can steal credentials that survive beyond the original infection. That turns a code dependency problem into an access-control incident, because the attacker gains reusable authentication material, not just a one-time foothold.

Q: Why do long-lived npm and GitHub tokens make supply chain worms harder to contain?

A: Because a stolen token is not just a credential, it is delegated authority. If it can publish packages or create workflows, the attacker can convert one compromise into repeated distribution and persistence. Short-lived, scope-limited tokens reduce how far a single theft can spread.

Q: How do security teams know whether a package compromise has become CI/CD persistence?

A: Look for new GitHub workflows, newly created repositories, unfamiliar runner registrations, and unusual audit-log entries tied to repository automation. The key signal is not only secret theft, but whether the attacker has established a repeatable execution path on self-hosted infrastructure.

Q: Who is accountable when stolen software supply chain credentials are used to publish malicious code?

A: Accountability sits across the maintainer, platform, and security functions because publishing rights, token scope, and runner governance all contribute to the failure. Under NHI governance, the owner of the credential lifecycle is responsible for limiting the blast radius of any stolen token.

Technical breakdown

How Shai-Hulud v2 turns package installs into secret harvesting

The first stage is execution through a package lifecycle hook. Infected packages add a preinstall script that runs during npm install, which means code executes before many teams have a chance to inspect runtime behaviour. The malware then scans .npmrc, environment variables, and local files for npm, GitHub, AWS, GCP, and Azure secrets. Tools such as Trufflehog are used as collection logic, but the important point is identity abuse: the package runs inside a trusted development or build context and inherits whatever secrets are already present.

Practical implication: Treat install-time execution as an identity event and restrict secrets exposure in developer and CI environments.

Why token scope determines whether the worm can self-propagate

Propagation depends on whether the stolen npm token is valid enough to publish packages. If the token has maintainer publishing rights, the worm can fetch a package tarball, modify package.json, inject setup_bun.js and bun_environment.js, repack the archive, and publish a new version. That is not brute force malware behaviour. It is delegated authority abuse, where a legitimate identity is used to extend compromise across the package ecosystem. Narrow token scopes and short-lived credentials matter because they change whether a stolen token is enough to turn one infection into many.

Practical implication: Limit npm token scope to the minimum publishing rights required and remove long-lived publish credentials from developer machines.

How GitHub Actions persistence changes the attack surface

The new persistence layer uses a vulnerable GitHub Action and self-hosted runners to preserve access beyond the initial package infection. Once a repository is touched, the malware can create workflow code that executes on a self-hosted runner when a discussion or similar event occurs. That shifts the compromise from code theft to runtime foothold inside CI infrastructure. The identity issue is that the runner, the workflow token, and the repository permissions are all being treated as normal automation rather than privileged execution paths that need stronger governance.

Practical implication: Separate build identities from repository identities and lock down self-hosted runner permissions and audit trails.

Threat narrative

Attacker objective: The attacker wants to harvest reusable secrets, propagate the worm through trusted package channels, and preserve access through CI/CD persistence.

1. Entry occurs when a maintainer installs an infected npm package and the preinstall hook executes with access to local files, environment variables, and developer secrets.
2. Escalation occurs when the malware validates a stolen npm token or GitHub token and uses that delegated authority to publish infected package versions or create workflow-based persistence.
3. Impact occurs when secrets are exfiltrated, infected packages spread to downstream users, and self-hosted runners become a durable execution foothold for further compromise.

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

Shai-Hulud v2 is a secrets governance failure disguised as package malware. The worm does not need a new exploit class to succeed because it feeds on already-trusted NHI material such as npm tokens, cloud keys, and GitHub credentials. That means the core control gap is not detection at the edge, but unmanaged secrets inside the software delivery chain. Practitioners should treat every package install path as an identity trust boundary.

Standing publishing authority is the real amplification point. Once a maintainer token is valid, the attacker inherits the ability to publish trust into the ecosystem at scale. That is the same structural weakness seen in many NHI incidents: a long-lived credential becomes a distribution mechanism for compromise. The implication is that publishing rights, not just source code, need lifecycle governance and continuous review.

GitHub Actions persistence expands the problem from secrets exposure to execution persistence. The article shows that an infected repository can be turned into a workflow-backed foothold on self-hosted runners. This is a named concept worth tracking: CI/CD identity sprawl, where repository tokens, workflow permissions, and runner identities are governed as separate domains even though an attacker can chain them together. Practitioners should regard that as one control plane, not three.

Encoded secrets are not a safe intermediate state. The article notes repositories with encoded but unencrypted secrets, and that matters because encoding does not change the attacker’s recovery cost once a package or workflow executes in a trusted environment. The broader lesson is that secrecy without revocation is only delay, not protection. Teams should stop assuming that hidden equals controlled.

This campaign validates the NHI principle that identity lifecycle is the control, not the dependency location. Packages, tokens, runners, and cloud keys all need offboarding, rotation, and scope review when an incident lands. The central governance error is to treat software artefacts as static while the identities behind them remain live and reusable. Practitioners should rebuild NHI lifecycle around the supply chain itself.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 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.
• That is why teams should also review The 52 NHI Breaches Report for the repeat failure modes that turn leaked credentials into durable compromise.

What this signals

CI/CD identity sprawl: the more build systems, workflow tokens, and runner identities you allow to accumulate, the more ways a single package compromise can become a persistent breach. In practice, that means your software delivery pipeline now behaves like an identity estate and should be governed that way.

The combination of package execution, token abuse, and runner persistence means traditional dependency scanning is only one control layer. Teams should expect attackers to target the credential paths around the dependency rather than the code itself, which is why token hygiene and workflow governance need to move into the same operational queue as vulnerability remediation.

With 64% of leaked secrets still valid and exploitable today, our research shows that revocation lag is now a primary exposure driver. For practitioners, that means building incident playbooks that remove reusable credentials first and treat repository cleanup as secondary containment.

For practitioners

• Audit install-time execution paths Search package manifests for preinstall, postinstall, and similar hooks that can run before review. Prioritise repositories that allow secrets in development or build environments, and remove unnecessary local credentials from those contexts.
• Rotate publishing and workflow tokens now Revoke npm tokens, GitHub tokens, and cloud provider keys exposed to affected repositories or runners. Where possible, move to short-lived credentials and verify that scopes do not include workflows or publishing rights unless required.
• Review self-hosted runner trust boundaries Inventory self-hosted runners, inspect GitHub audit logs for newly created repositories or suspicious runner registration, and reimage hosts that may have executed malicious workflow code. Treat runner identity as privileged infrastructure access.
• Block persistence through workflow governance Restrict who can create or modify GitHub Actions workflows, especially in repositories that can publish packages. Use branch protections and separate approval paths for workflow changes so a package compromise cannot automatically become CI persistence.

Key takeaways

• Shai-Hulud v2 shows that npm supply chain compromise is now an identity problem involving tokens, workflow permissions, and runner trust.
• Leaked secrets remain dangerous long after discovery, which is why the control failure is usually revocation and scope management rather than detection alone.
• Practitioners should treat package publishing rights and GitHub Actions permissions as part of the same NHI lifecycle and harden them together.

Key terms

• Supply Chain Identity: The collection of credentials, tokens, workflow permissions, and publishing rights that let software move from source to deployment. In NHI terms, it is the identity layer of the pipeline, and when it is weak, compromise can propagate through legitimate automation rather than obvious malware channels.
• CI/CD Identity Abuse: Misuse of pipeline identities, workflow permissions, or build artifacts to execute attacker-controlled actions. This usually looks like legitimate automation, but the goal is to steal secrets, alter code, or extend access through trusted build infrastructure.
• Standing Publishing Authority: A persistent credential or permission that can publish software, modify workflows, or register runners without time-bounded approval. It is risky because once stolen, it gives attackers durable authority to turn one package compromise into repeated distribution or persistence.
• Secret Revocation Lag: The delay between a secret being exposed and that secret actually being invalidated everywhere it can be used. In NHI governance, the gap is often more dangerous than discovery itself because exposed credentials can remain operational long after teams believe the incident is contained.

What's in the full analysis

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

• The exact malicious file changes added to infected repositories, including the preinstall hook and workflow persistence code.
• Step-by-step detection queries for GitHub audit logs, repository search, and affected runner identifiers.
• Concrete remediation steps for maintainers, including package rollback, cache cleaning, and token rotation sequencing.
• The specific Semgrep rules and auto-scan workflow used to detect the persistence payload.

👉 Semgrep's full post covers the malware chain, persistence workflow, and remediation steps in more detail.

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 building or maturing an IAM programme, it is worth exploring.