Shai-Hulud npm supply chain attack exposes NHI trust gaps

At a glance

What this is: This is Orca Security’s analysis of the second Shai-Hulud npm campaign, which used trojanised packages and compromised maintainer identities to steal secrets and spread across the registry.

Why it matters: It matters because npm trust, CI/CD permissions, and cloud credential handling are tightly linked, and failures in one layer can rapidly expose both machine and human identity controls.

By the numbers:

• A total of 425 compromised packages were detected with an estimated 132 million monthly downloads.
• In some bursts, about 1,000 new repositories were being added every 30 minutes.

👉 Read Orca Security's analysis of the Shai-Hulud npm supply chain campaign

Context

The Shai-Hulud campaign is a supply chain compromise that turns package installation into a credential-harvesting step. In practical terms, malicious code ran during pre-install or post-install hooks, which let attackers pull developer tokens, CI/CD secrets, and cloud metadata before defenders could treat the package as “just code.”

For identity teams, the problem is not limited to npm hygiene. It exposes how much modern delivery depends on non-human identities, especially maintainer tokens, pipeline credentials, GitHub workflows, and cloud access keys. Once those identities are abused, the same trust chain can be used to spread laterally, persist inside repositories, and exfiltrate data at scale.

Key questions

Q: What breaks when a malicious npm package can run install-time scripts?

A: The trust boundary breaks at the point of installation, because the package is no longer just a dependency. It can execute code in the build context, read environment variables, access cloud metadata, and collect secrets before the defender ever reviews the package contents. That is why install-time execution must be governed as an active control point, not a passive delivery step.

Q: Why do compromised maintainer tokens create more risk than a single bad package?

A: A compromised maintainer token turns registry trust into a propagation path. The attacker can republish additional packages under a legitimate namespace, which extends the attack beyond one artifact and into the maintainer’s broader distribution authority. That makes publisher identity, token scope, and release lifecycle controls central to supply chain defense.

Q: How can security teams tell whether secret exposure from package installs is contained?

A: Containment is real only when exposed credentials are revoked, replacement identities are least privileged, and the build and repository estate has been searched for persistence markers. If old tokens, workflows, or runners remain active, the exposure is still live even if the original malicious package is removed.

Q: What should organisations do when npm supply chain compromise is suspected?

A: Start by removing the compromised packages, clearing build caches, rebuilding from clean dependencies, and rotating any token that could have been present during install. Then inspect GitHub workflows, runner registrations, and repository history for persistence, because a package compromise often leaves behind identity-based footholds.

Technical breakdown

Install-time script execution in npm packages

npm packages can execute code automatically through pre-install and post-install hooks. That makes package installation a runtime trust event, not just a dependency fetch. In this campaign, malicious scripts dropped payload files such as setup_bun.js and bun_environment.js, then used the local execution context to read environment variables, access cloud metadata, and enumerate secrets. The architectural issue is that package provenance and package behaviour are not the same thing. A package may look legitimate in source control while still executing attacker-controlled logic during install.

Practical implication: restrict or disable install-time scripts where feasible and treat package installation as an execution control point.

Maintainer token compromise and registry propagation

The worm-like spread depended on compromised maintainer identities. Once attackers stole a maintainer token, they could republish additional packages under that maintainer’s namespace, which gave the malware a trusted distribution path and let it move laterally across the npm registry. This is a classic non-human identity failure: the package publisher identity became the attack vehicle. The risk is not only initial compromise, but delegated publishing authority that persists beyond the first stolen credential.

Practical implication: scope publishing tokens tightly, rotate them aggressively, and separate package release identity from general developer access.

Pipeline persistence through GitHub Actions and self-hosted runners

The campaign extended beyond package compromise into GitHub infrastructure by adding workflows, self-hosted runners, and repository artefacts designed to preserve access and exfiltrate secrets. That matters because CI/CD systems often have broad access to source, secrets, artifacts, and cloud environments. When a malicious workflow can run on a self-hosted runner, the attacker is no longer limited to package installation. They can use the pipeline as a control plane for discovery, collection, and cover-up.

Practical implication: review GitHub Actions, runner registration, and workflow-change controls as part of identity governance, not just DevSecOps.

Threat narrative

Attacker objective: The attacker aimed to steal high-value non-human credentials, extend trust to additional packages, and turn developer and pipeline identities into a distribution and exfiltration channel.

1. Entry occurred through trojanised npm package versions that executed during install via pre-install or post-install hooks.
2. Credential access followed when the malware harvested developer tokens, CI/CD secrets, and cloud metadata from the execution environment.
3. Impact expanded as compromised maintainer tokens were used to republish more packages and to seed malicious workflows, runners, and repositories for persistence and exfiltration.

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

Package trust is now an identity problem, not just a software integrity problem: The campaign works because the build ecosystem treats package provenance as if it were sufficient assurance. It is not, because install-time execution turns a dependency into an active identity-bearing actor with access to secrets, metadata, and pipeline state. Practitioners need to treat package execution, publishing tokens, and workflow permissions as one governance plane, not separate hygiene tasks.

Maintainer token abuse is the real lateral movement path in npm supply chain attacks: Once a maintainer credential is compromised, registry trust becomes a propagation mechanism. That is why this is more than simple package tampering. The attacker inherits the ability to republish within a trusted namespace, which collapses the distinction between source control identity and software distribution identity. Identity teams should read this as a publisher lifecycle failure, not a code-review miss.

Secret exposure persists because revocation lags discovery: The campaign’s ability to collect cloud credentials and CI/CD tokens shows how quickly secrets can be harvested during routine installs. The point is not that secrets exist, but that their lifecycle is too long and their blast radius is too broad. Mature programmes need to assume that exposed secrets can be operationally usable long after detection, especially where publishing and pipeline credentials are shared.

Shai-Hulud creates an identity blast radius that spans developers, pipelines, and cloud control planes: The same attack chain crosses human-issued tokens, NHI credentials, and build-system identities. That makes it a useful named concept for this class of incident: the identity blast radius is the total downstream trust surface created when a single compromised publishing identity can touch registry distribution, CI/CD execution, and cloud metadata. Practitioners should map that blast radius before the next package compromise forces the issue.

OWASP NHI controls map directly to this failure pattern: Secret sprawl, over-privileged publishing access, and inadequate lifecycle offboarding all show up in the campaign path. The article reinforces that machine identities in development pipelines need the same discipline as production workloads, because compromise during build can be as damaging as compromise at runtime. The practical takeaway is to govern NHI access by lifecycle stage, not by team convenience.

From our research:

• AI-related credential leaks surged 81.5% year-over-year in 2025, according to the State of Secrets Sprawl 2026.
• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to the State of Secrets Sprawl 2026.
• Forward look: Guide to the Secret Sprawl Challenge shows how teams can reduce exposure windows before the next supply chain campaign lands.

What this signals

Secret lifecycle, not secret discovery, is the decisive control gap: once credentials can be harvested during package installation, the programme only succeeds if revocation, replacement, and scope reduction happen faster than attacker reuse. The 81.5% year-over-year rise in AI-related credential leaks reported in our State of Secrets Sprawl 2026 shows that the exposure problem is accelerating, not stabilising.

Identity blast radius should become a standard operating concept for CI/CD governance: teams need to measure how far a single publishing credential can reach across registries, workflows, cloud metadata, and self-hosted runners. If the blast radius is unknown, the organisation cannot prove that package compromise is contained.

The right response is to align software supply chain controls with identity lifecycle discipline, not treat them as separate programmes. That means publishing tokens, GitHub workflows, and cloud access keys should all be governed as revocable identities with explicit ownership and offboarding.

For practitioners

• Inventory package publishing identities Identify every npm publishing token, GitHub credential, and automation identity that can publish to your registries. Separate production release credentials from day-to-day developer access and document where each token is used.
• Disable or constrain install-time scripts Review whether preinstall and postinstall hooks are necessary in your environments. Where they are unavoidable, restrict execution to trusted packages, isolate builds, and monitor for unexpected file drops or outbound connections during install.
• Rotate and revoke exposed secrets immediately Treat any exposed npm, GitHub, or cloud credential as compromised until proven otherwise. Revoke publishing tokens, personal access tokens, SSH keys, and cloud provider credentials, then verify that replacement identities are least privileged.
• Audit GitHub Actions and self-hosted runners Search for unexpected workflows, newly created branches, and runners with suspicious names or recent registration events. Verify that workflow approvals, repository write access, and runner permissions are tightly controlled across all projects.

Key takeaways

• Shai-Hulud shows that npm supply chain compromise is an identity and secrets governance failure, not only a package integrity issue.
• The scale is material, with more than 25,000 repositories and 425 compromised packages exposed in the campaign.
• The most effective limiters are rapid credential revocation, install-time script control, and strict governance over publishing identities and CI/CD runners.

Key terms

• Install-time script execution: Code that runs automatically when a package is installed, rather than when a developer explicitly starts it. In supply chain attacks, this matters because the install step can access environment secrets, cloud metadata, and filesystem contents before normal application controls are in place.
• Maintainer token: A non-human credential that authorises a trusted package maintainer to publish or update software in a registry. If stolen, it becomes a distribution authority, allowing attackers to push malicious versions under a legitimate namespace and extend compromise beyond one package.
• Self-hosted runner: A CI/CD execution environment managed by the organisation rather than the platform vendor. It often has broad access to source, secrets, and deployment targets, which makes it a high-value persistence and exfiltration point if workflow controls are weak.
• Identity blast radius: The total downstream scope of damage created when one identity is compromised, including what systems, workflows, data stores, and distribution channels become reachable. For NHI programmes, it is a practical way to measure how far a single token or account can travel before containment stops it.

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.

This post draws on content published by Orca Security covering the Shai-Hulud npm supply chain campaign: LLMjacking-inspired credential abuse and package compromise analysis. Read the original.