Shai-Hulud shows how npm supply chain attacks now self-propagate

At a glance

What this is: This is an analysis of the Shai-Hulud npm campaign, where trojanised packages self-propagated through the registry and turned one maintainer compromise into a wider supply chain outbreak.

Why it matters: It matters because CI/CD runners, maintainer tokens, and package publishing rights are part of the attack surface, so IAM and NHI governance now have to cover software supply chain trust, not just human accounts.

By the numbers:

• The campaign impacted over 180 packages across the ecosystem.

Context

Shai-Hulud is a supply chain attack pattern in which a compromised package is used as a delivery vehicle for credential theft, persistence, and propagation. The core governance gap is that build and publish pipelines often trust package install behaviour more than they should, especially when tokens, runners, and maintainer accounts are treated as separate control domains.

In this case, the problem is not just malicious code in an open-source dependency. It is the reuse of valid credentials, the execution of post-install logic inside CI/CD, and the ability for one compromised maintainer to affect multiple packages. For IAM and NHI teams, this is the point where software supply chain security becomes identity governance.

The article describes a realistic and now familiar failure mode for modern development environments: once the pipeline trusts the package, the package can attack the pipeline. That makes this a typical exposure pattern, not an edge case.

Key questions

Q: What breaks when a malicious npm package can reuse maintainer credentials and republish itself?

A: The failure is recursive trust. Once a package can republish from a valid maintainer context, one compromise can become many, because publication rights are reused as propagation rights. That breaks the assumption that registry compromise stays local to a single package, and it forces teams to control ownership, token scope, and publish approvals as part of supply chain security.

Q: Why do CI/CD secrets create such a large blast radius in supply chain attacks?

A: CI/CD secrets are often shared across build, publish, and cloud tasks, so one exposed token can touch many systems at once. In this incident, the same compromise path reached GitHub, npm, AWS, GCP, Azure, Vault, SSH, and database credentials. That makes token scope and runner isolation central to blast-radius reduction.

Q: How do security teams know if npm dependency controls are actually working?

A: Look for fewer package installs that execute scripts unexpectedly, fewer child processes from node.exe, and no outbound connections from build agents to unapproved domains during dependency resolution. Effective controls should make malicious install-time behaviour visible and, where possible, block it before code reaches the endpoint.

Q: Should teams prioritise package provenance or secret rotation first after a registry compromise?

A: They should do both, but secret rotation comes first when install-time execution has already occurred. Provenance controls reduce future exposure, while rotated and revoked secrets cut off the attacker’s immediate ability to persist, republish, or move laterally through CI/CD and GitHub. Recovery is slow if credential reuse remains intact.

Technical breakdown

How trojanised npm packages execute inside build pipelines

npm install can execute package lifecycle scripts such as post-install hooks, which means a malicious release can run code during routine dependency installation. In the Shai-Hulud campaign, the payload was a large minified bundle hidden behind an ordinary package update, allowing the attacker to blend malicious execution into normal CI/CD behaviour. The technical risk is not the package manager alone but the assumption that installation is passive. Once install-time execution is permitted, the dependency becomes a runtime actor inside the pipeline.

Practical implication: Treat package installation as executable code, not metadata, and restrict where and how CI runners can execute dependency scripts.

Why CI/CD secrets and maintainer tokens are the real propagation fuel

The campaign used secrets discovery to harvest environment variables, local files, and GitHub credentials, then used those tokens to deepen access. That matters because package compromise becomes materially worse when the build environment contains reusable secrets with publish or repo access. In NHI terms, the attacker is abusing high-value machine credentials and delegated publishing rights, not just stealing source code. The attack chain is a credential-to-propagation loop: harvest secrets, use them to gain more reach, then continue the spread.

Practical implication: Inventory CI/CD secrets, reduce token scope, and remove any credential that can both access repos and publish packages.

How self-replication turns one compromise into an ecosystem outbreak

The worm-like behaviour is what separates this from a routine malicious package. When the malware finds an npm token, it can automatically bump and republish every package owned by the compromised maintainer, creating a multi-package propagation path without human intervention. That changes the threat model from isolated compromise to recursive spread. The same logic applies to any software ecosystem where a privileged publishing credential can be reused across multiple artifacts, registries, or repositories.

Practical implication: Build controls around maintainer scope, package ownership, and publish-time approvals so one credential cannot replicate across an entire package estate.

Threat narrative

Attacker objective: The attacker aimed to turn a single maintainer compromise into persistent, self-propagating access across the npm ecosystem while harvesting CI/CD and GitHub secrets.

1. Entry began with reused maintainer credentials that allowed trojanised releases of @ctrl/tinycolor and related packages to be published into npm.
2. Credential access followed as the malicious post-install script dumped environment variables, scanned files with TruffleHog, and planted a GitHub Actions workflow to collect future secrets.
3. Escalation and propagation occurred when stolen npm tokens and GitHub tokens were used to republish packages and expose private or sensitive repositories.
4. Impact was ecosystem-wide, with more than 180 packages affected and downstream consumers exposed to secret theft, repository compromise, and persistence in CI/CD.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• 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.

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

Self-propagating package malware is now a governance problem, not just a malware problem. The important shift in Shai-Hulud is that the payload did not stop at theft or sabotage, but used valid package and GitHub credentials to replicate itself. That means the control question is no longer whether a dependency was malicious, but whether the surrounding publishing and CI trust model can contain recursive abuse. Practitioner implication: govern package publication as a privileged workflow, not a routine developer task.

CI/CD runners have become non-human identities with outsized blast radius. The article shows that build agents, tokens, and automation paths now carry the trust that attackers want most. In OWASP-NHI terms, this is a combination of secret leakage, overprivileged NHI access, and weak offboarding for ephemeral build credentials. Practitioner implication: treat runners, tokens, and workflows as governed identities with explicit scope, rotation, and revocation.

Package trust is now inseparable from supply chain trust. The campaign demonstrates that software provenance is only as strong as the credentials used to publish and execute it. A maintainer account with reusable tokens can become a distribution channel for malware across an entire estate. Practitioner implication: move from dependency review alone to end-to-end supply chain governance, including maintainer access, build provenance, and publish controls.

Shai-Hulud illustrates a named control gap: recursive credential reuse. The breach pattern works because the same identity material can be used first to infect, then to persist, and then to propagate. That is a failure of lifecycle control, not simply a failure of detection. Practitioner implication: design controls that break the reuse chain before publication rights can be re-exercised.

Supply chain attacks now reward attackers who can behave like automation. The more a malicious payload can hide inside routine install and publish actions, the more it can scale without direct operator touch. That makes blast-radius containment the decisive security objective for software delivery teams. Practitioner implication: prioritise containment of publish credentials and CI execution paths over after-the-fact package cleanup.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Recursive credential reuse: this campaign shows how one maintainer token can be used first to infect, then to persist, and then to propagate across an entire package estate. That is why software supply chain governance now has to cover publication rights, runner identity, and revocation at the same time.

The practical signal for security teams is that package trust and identity trust have converged. If CI/CD runners can execute install-time scripts while holding publish or cloud access, the attacker has already been granted a path from dependency compromise to infrastructure compromise.

The scale of the pattern matters: 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026. That tells practitioners where to harden first, and why runner identity deserves the same governance attention as human privileged access.

For practitioners

• Harden npm publish rights Restrict package publication to narrowly scoped maintainer roles, separate publish privileges from everyday development access, and require explicit approval for ownership changes or mass republishing events.
• Treat CI runners as governed identities Inventory build runners, service tokens, GitHub workflows, and other non-human identities that can execute install-time code or access secrets, then define ownership and rotation for each.
• Block install-time script execution where possible Disable or tightly control post-install execution in CI for untrusted dependencies, and isolate builds that must execute scripts from systems holding publish or cloud credentials.
• Rotate every exposed credential from affected build paths Revoke npm tokens, GitHub tokens, SSH keys, and cloud access keys used on runners or developer systems that executed the malicious install window, then rebuild those environments cleanly.
• Search for propagation indicators across repos and workflows Hunt for malicious bundle.js artefacts, shai-hulud workflow files, suspicious forks, and unusual package version bumps across internal code and CI estates.

Key takeaways

• Shai-Hulud shows that npm compromise is now a propagation problem, not only a malicious-package problem.
• The campaign's impact came from the overlap of install-time execution, CI/CD secrets, and reusable publishing credentials.
• Containment depends on breaking credential reuse, narrowing publish rights, and treating build runners as governed identities.

Key terms

• Self-Propagating Supply Chain Worm: A self-propagating supply chain worm is malicious code that spreads by abusing trusted software distribution paths. It compromises a package, update, dependency, or build process, then automatically infects downstream systems and connected environments. In security terms, it weaponizes trust relationships, signing workflows, and automation to expand without repeated attacker action.
• Build-Time Code Execution: Build-time code execution occurs when a package install or build process runs commands before the software is fully installed. This is risky because dependency fetches, lifecycle scripts, and helper tools can execute with developer or root privileges. It turns ordinary package management into a potential host compromise path.
• Build Runner Identity: A build runner identity is the account, role, or token used by CI or developer automation while packages are installed and software is assembled. It often has broader reach than a normal user session, which makes it a valuable target when malicious code executes during dependency installation.
• Recursive Credential Reuse: A failure pattern where the same token or account can be used to compromise a system, then persist in it, then expand access through the same permissions again. In software supply chains, this turns publication rights and CI access into a propagation mechanism.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course covers NHI governance, machine identity security, and secrets management, the industry's only accredited NHI security programme. It helps practitioners connect identity controls to the operational risks that shape modern software and cloud environments.