Shai-hulud showed how npm supply chains fail on identity trust

At a glance

What this is: This is a CyberArk analysis of the Shai-Hulud npm worm, which spread through package trust relationships by stealing developer and machine credentials and turning compromised maintainers into propagation points.

Why it matters: It matters because IAM, PAM and NHI programmes now have to govern developer accounts, tokens and CI/CD identities as part of software supply chain defence, not as separate concerns.

Context

Shai-Hulud is a supply chain worm that exploited the identity trust embedded in npm package publishing and consumption. The article shows that the primary problem was not only malicious code in packages, but the compromise of developer accounts, tokens, API keys and other machine credentials that made package publishing possible.

For identity teams, the key failure mode is that package ecosystems still assume maintainers and automation identities are trustworthy at the moment of publish. Once those identities are stolen or reused, the attacker inherits the ability to publish, exfiltrate and persist through normal CI/CD activity.

This is a classic NHI governance problem with human identity overlap. The article ties maintainer access, token handling, secret sprawl and build pipeline trust together, which is why the blast radius extended far beyond a single repository.

Key questions

Q: What breaks when an npm maintainer identity is compromised in a CI/CD pipeline?

A: The release process itself becomes part of the intrusion path. A compromised maintainer identity can publish malicious versions, trigger trusted workflows, and reuse automation secrets to keep spreading. The failure is not only malware execution, but uncontrolled authority over package publication and the CI/CD identities that support it.

Q: Why do npm tokens and build credentials increase supply chain risk so quickly?

A: Because they are reusable non-human identities with privileges that outlive a single session. If an attacker steals a token that can publish packages or write automation, the compromise can spread from one repository to many others, turning a local infection into ecosystem-wide propagation.

Q: What are the signs that a package publishing workflow has been compromised?

A: Common warning signs include unexpected package version bumps, releases from inactive or former employee accounts, changes to dependency behavior without a planned release, and traffic or transaction patterns that do not match normal application use. Security teams should also watch for unsigned or unreviewed updates, sudden publishing outside normal change windows, and user reports that align with a recent package release.

Q: How should teams separate release authority from CI/CD automation?

A: Treat release authority as privileged access and keep it distinct from build execution and secret retrieval. Automation should not inherit broad publish rights by default, and build identities should not be able to use the same secrets that authorise package release. That separation limits how far a single compromise can travel.

Technical breakdown

How npm maintainer identity becomes the entry point

Package registries such as npm depend on publisher trust, so compromise usually starts with maintainer credentials, tokens or a captured session rather than a software exploit. In this case, CyberArk describes likely phishing, token theft, credential reuse or a compromised workstation as plausible entry paths. Once a maintainer identity is taken over, the attacker can publish as a trusted source, and the registry treats the update as legitimate. That trust model is fragile because publishing authority is the control plane, not just the code.

Practical implication: treat package publishing rights as privileged access and bind them to phishing-resistant authentication, token review and strong recovery controls.

Why stolen tokens and secrets give the worm its reach

The worm did not rely on one credential. It harvested npm tokens, GitHub tokens, cloud keys and other secrets from local files, environment variables and build contexts, then used those secrets to move from one identity to the next. That is classic NHI chaining: a token is not just an authenticator, it is delegated authority with enough scope to publish, access repositories or query cloud services. The article also shows why long-lived secrets are dangerous. They expand the time window in which a single leak can be weaponized.

Practical implication: inventory tokens as NHIs, shorten their lifetime, and remove broad publish or cloud scope from credentials used in developer workflows.

How CI/CD workflows turn identity theft into supply chain spread

Shai-Hulud weaponized normal automation. After stealing access, the malware pushed malicious package updates, injected GitHub Actions workflows and used build and release paths to persist and spread. That means the attack was not just about code execution on a developer endpoint. It was about abusing trusted automation paths that already had permission to publish, retrieve secrets and trigger downstream builds. Once CI/CD identities are overly trusted, the boundary between developer machine and production software distribution disappears.

Practical implication: separate build, publish and secret-access identities so compromise of one pipeline component cannot authorize package propagation.

Threat narrative

Attacker objective: The objective was to turn trusted package maintainers and automation identities into a self-propagating distribution channel for secret theft and package compromise.

1. Entry began with compromise of maintainer access, most likely through phishing, token theft, reuse or another account takeover path.
2. Credential harvesting followed as the worm extracted npm tokens, GitHub credentials, cloud keys and other secrets from the local and build environment.
3. Escalation came through trusted publish privileges, which let the attacker push trojaned package versions and inject persistence into GitHub Actions workflows.
4. Impact was supply chain-wide propagation, with poisoned packages and stolen secrets spreading beyond the original victim into downstream consumers.

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.
• Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.

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

Identity trust, not code trust, is the decisive control surface in npm supply chains. The article shows that package managers fail when they assume the publisher is still the legitimate owner at the moment of release. Once maintainer credentials or tokens are stolen, the attacker can operate inside ordinary release workflows and the registry has little reason to question the action. Practitioners need to treat publisher identity as the primary trust boundary.

Long-lived developer and machine secrets create a reusable blast-radius engine. Shai-Hulud worked because the same secret classes that enable convenience also enable propagation: tokens, API keys and cloud credentials. That is exactly the kind of delegated authority NHI governance is supposed to control. When those secrets live too long, are too broad or are reused across environments, one compromise becomes many. The implication is that credential lifecycle is now supply chain security, not just IAM hygiene.

Secret sprawl across endpoints, repos and CI/CD has become a supply chain risk pattern. The worm harvested from files, environment variables and workflow contexts, which means the exposure surface spans developer machines and automation paths at once. This is where human identity and NHI governance intersect: the maintainer account may be human, but the durable attack leverage comes from machine credentials attached to that human workflow. Teams should read this as a cross-domain governance failure, not a single compromised user account.

Software publishing now behaves like privileged infrastructure administration. When package release rights can alter downstream environments at scale, they deserve the same governance discipline as PAM-managed admin paths. That means reviewable privilege, scoped issuance and strong separation between development access and release authority. The field should stop treating open source publishing as routine collaboration and start treating it as high-impact privileged execution.

Identity blast radius is the right concept for modern supply chain defence. A single stolen maintainer identity can cascade into package tampering, secret exfiltration and downstream build compromise. This is not just lateral movement in the classic endpoint sense. It is lateral movement through trust relationships that were never designed for adversarial use. The practitioner conclusion is clear: govern the identity chain, not just the dependency chain.

From our research library:

• 42% of machine identities have privileged access and 61% of organisations lack identity security controls for cloud workloads, according to CyberArk's 2025 Identity Security Landscape.
• Read next: Ultimate Guide to NHIs

What this signals

Identity blast radius: package ecosystems should now be governed as trust networks, not as collections of isolated artifacts. When a maintainer account can publish, a token can authenticate, and CI/CD can persist that authority, the compromise surface spans people, machine identities and release automation in one chain.

Teams should expect more attacks that target the publish path rather than the package contents themselves. The practical shift is to move enforcement earlier, at issuance and authorisation time, because review after publication cannot undo a trusted identity that has already been abused.

For practitioners

• Lock down maintainer publishing rights Require phishing-resistant MFA, remove legacy password-only access and restrict package publishing to tightly governed identities with explicit approval paths.
• Shorten the lifetime of developer and pipeline secrets Rotate npm tokens, cloud keys and GitHub credentials aggressively, then replace broad long-lived secrets with short-lived issuance where possible.
• Scan developer and CI/CD contexts for exposed secrets Search repositories, logs, environment variables and workflow files for tokens, API keys and cloud credentials, then revoke any discovered secret immediately.
• Separate publishing, build and secret-access identities Keep package publish privileges distinct from build execution and secret retrieval so compromise of one path cannot authorise the others.
• Review third-party and automation app permissions Audit OAuth apps, CI integrations and recovery channels that can publish packages or read secrets, then remove unused access and narrow the remaining scope.

Key takeaways

• Shai-Hulud showed that npm supply chain compromise is driven as much by identity trust as by malicious code.
• The article describes more than 500 compromised packages and a worm that reused stolen credentials to spread through trusted release paths.
• The clearest defence is tighter control over maintainer identities, token lifecycle and CI/CD publishing privileges.

Key terms

• Package Publishing Identity: The account, token, or workflow that authorises a software package release into a registry. In practice, this identity behaves like a privileged non-human identity because compromise lets an attacker publish trusted code to many downstream consumers.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Release Path Privilege: The privileged ability to move code from development into a published artifact or package release. This privilege deserves governance like PAM because abuse at the release stage can distribute malicious content at scale and bypass ordinary code review expectations.

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.