Shai-Hulud 2.0 shows supply chain worms are now identity attacks

At a glance

What this is: This is a supply chain security analysis of Shai-Hulud 2.0, showing how a self-replicating npm worm turned developer trust, package publishing rights, and stored secrets into an identity and propagation problem.

Why it matters: It matters because the blast radius now depends on non-human identity hygiene, package trust, and workflow privilege, not just endpoint detection or production hardening.

By the numbers:

• Over 640 npm packages with 132 million monthly downloads were compromised.
• The first Shai-Hulud wave compromised 180+ packages and stole $50 million in cryptocurrency.
• Wiz's analysis showed that compromised packages like @postman/tunnel-agent exist in 27% of cloud environments.

👉 Read Knostic's analysis of the Shai-Hulud 2.0 npm supply chain worm

Context

Shai-Hulud 2.0 is best understood as a supply chain worm that turns package trust into credential theft and propagation. In plain terms, the malware executes before install completes, uses a two-stage payload, and spreads through developer and CI/CD environments by abusing publishing rights and exposed secrets.

For identity teams, the key issue is not simply malware detection. The article shows how npm, GitHub Actions, cloud keys, and developer tokens form an identity chain that can be abused at scale when standing access and unattended execution are left in place.

That starting position is increasingly typical, not exceptional. Modern engineering environments commonly combine trusted packages, automation, and long-lived credentials, which gives a self-replicating worm enough access to move faster than human review cycles.

Key questions

Q: What breaks when npm package installs are allowed to execute code before inspection?

A: The control point disappears. If install-time code can run before review, malware can harvest secrets, alter workflows, and propagate before defenders see a stable artifact. That makes preinstall hooks an execution surface, not a packaging detail. Teams should assume installation is a potential compromise event and enforce policy before code reaches that stage.

Q: Why do package manager credentials increase supply chain worm risk?

A: Because publishing rights become propagation rights. A stolen npm or GitHub token does not just expose one account, it can let an attacker republish malicious packages, create repositories, and push tainted updates downstream. That is why these secrets need the same governance as privileged production credentials.

Q: What do security teams get wrong about workflow runner persistence?

A: They treat runners as disposable build machinery instead of identities that can preserve access. A self-hosted runner can become a durable foothold if offboarding, isolation, and monitoring are weak. If the runner still has access after the job ends, the attacker may still have a path back in.

Q: How should teams respond when a supply chain worm spreads through trusted packages?

A: Contain the publishing surface first. Revoke exposed tokens, rotate credentials, review repository creation and workflow changes, and roll back to known-clean package versions. Then scope the blast radius across developer environments, CI/CD systems, and any cloud accounts that shared the same secrets.

Technical breakdown

Preinstall execution turns package install into an attack surface

The attack runs during the preinstall phase, before dependencies fully resolve, which means the compromise happens at a stage many security tools do not inspect closely. The setup_bun.js loader installs Bun to evade controls that focus on Node.js, then launches a heavily obfuscated payload. That design matters because package installation is no longer just code retrieval. It is code execution, often inside developer workstations and CI/CD runners that inherit broad trust.

Practical implication: instrument package install paths, not just production deployments, and inspect preinstall scripts as executable code.

Credential harvesting converts developer trust into propagation rights

Once active, the worm scans for credentials with TruffleHog, then collects GitHub tokens, npm tokens, and cloud credentials from AWS, GCP, and Azure. Those secrets are not only exfiltration targets. They are the mechanism that lets the worm republish malicious packages and create more compromised repositories. This is classic identity abuse in a software supply chain setting, where a maintainer's publishing authority becomes the propagation engine.

Practical implication: treat publishing credentials as high-value NHI secrets and scope them so compromise cannot fan out across ecosystems.

Persistent GitHub Actions runners extend the worm's lifetime

The campaign adds persistence through self-hosted GitHub Actions runners, which gives the attacker a foothold even after the initial package artifact is removed. That persistence layer matters because the worm does not need to remain in one package to keep operating. It can re-enter through workflows, republish from compromised accounts, and keep reinfecting downstream consumers. The result is a propagation model that blends supply chain abuse with identity persistence.

Practical implication: review workflow runners as non-human identities with lifecycle controls, not as temporary build conveniences.

Threat narrative

Attacker objective: The attacker objective is to turn trusted package maintenance and stored credentials into a self-replicating distribution channel that steals secrets, repackages malware, and broadens compromise across software ecosystems.

1. Entry occurred when compromised npm packages executed a preinstall payload inside developer and CI/CD environments, turning normal package installation into initial code execution.
2. Credential harvesting followed as the worm scanned for GitHub, npm, and cloud secrets, then used those credentials to republish malicious packages and create new attacker-controlled repositories.
3. Impact came through rapid propagation, with thousands of repositories created, hundreds of packages compromised, and downstream environments exposed to data theft, persistence, and supply chain spread.

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 publishing rights are now a non-human identity problem, not just a developer hygiene problem: the worm succeeds because publishing credentials, workflow tokens, and repository permissions can be chained together faster than human review. The article shows that the attacker does not need a traditional exploit when non-human identities already have enough authority to republish code and create persistence. Practitioners need to treat package maintainers, CI runners, and automation tokens as governed identities with lifecycle state, not as incidental tooling.

Standing credential exposure window: this attack worked because package, cloud, and GitHub credentials remained valid long enough to be discovered, reused, and weaponized. That assumption was designed for human-paced remediation and periodic review. It fails when malware can scan, harvest, and re-deploy within the same install or workflow cycle. The implication is that access review cadence alone does not match the tempo of supply chain worms.

Identity blast radius is now measured by publishing reach: a single compromised maintainer can touch hundreds of packages, thousands of repositories, and millions of downstream downloads when authority is reused across ecosystems. OWASP-NHI and NIST CSF both point to the same failure pattern, which is overextended trust in non-human credentials. Practitioners should reassess how much replication power sits inside a single token or workflow secret.

Preinstall execution breaks the old assumption that install-time code is passive: the article shows that package managers have become execution environments, so install time is no longer a safe boundary. That changes the governance question from 'Can we scan production artifacts?' to 'Where are we allowing code to run before control points exist?' The result is a stronger case for runtime inspection at the developer edge.

Persistence through workflow runners shows that cleanup is a lifecycle issue: removing a malicious package is not enough when self-hosted runners and linked automation can preserve access. This is a classic lifecycle failure across NHI and build systems, where offboarding never fully happened. Practitioners should align build identity governance with lifecycle discipline rather than treating runners as disposable infrastructure.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The 52 NHI breaches Report helps teams compare secret exposure patterns against real-world breach cases.

What this signals

Identity blast radius now follows build and publish rights: once a developer token can trigger republishing, the security boundary moves from production to the package ecosystem. That means IAM, secrets management, and CI/CD governance have to be evaluated together, not as separate programmes.

The operational signal is clear. If leaked secrets still take 27 days to remediate on average, as our research shows, a worm that harvests and reuses those secrets can outrun the response cycle without needing novel exploit chains.

Teams should expect more attacks that blend code execution, credential theft, and workflow persistence. The practical response is to map package publishing, runner access, and secret rotation into the same control plane instead of leaving them in different ownership silos.

For practitioners

• Classify package publishing tokens as governed NHI secrets Inventory npm, GitHub, cloud, and CI/CD credentials that can publish code or trigger workflows. Assign owners, set expiration expectations, and require revocation paths that are tested before incidents occur.
• Block preinstall execution where business risk allows Audit package installation pipelines for preinstall and install hooks, then decide where these scripts can be disabled or sandboxed. The goal is to prevent code from running before inspection and policy enforcement.
• Harden self-hosted runners as persistent identities Treat self-hosted GitHub Actions runners as lifecycle-managed identities with strong isolation, monitored permissions, and explicit offboarding. Remove any runner that can retain access after the associated job or repo is closed.
• Search for propagation indicators across repos and secrets stores Look for the Sha1-Hulud marker, unexpected repository creation, unusual package republishing, and credential-scanning behaviour. Use that evidence to scope exposure across GitHub, npm, and cloud access paths.

Key takeaways

• Shai-Hulud 2.0 shows that software supply chain worms now exploit identity authority, not just vulnerable code.
• The scale was extraordinary, with more than 640 packages, 25,000 malicious repositories, and 132 million monthly downloads affected.
• Controls fail when preinstall execution, publishing credentials, and persistent workflow runners are treated as low-risk operational details.

Key terms

• Preinstall Execution: Preinstall execution is code that runs before a package finishes installing. In supply chain attacks, that timing matters because it lets malicious logic execute before many scanners, policy checks, and human reviews can intervene, turning installation into a compromise point rather than a delivery step.
• Publishing Credential: A publishing credential is a token or secret that authorises code release to a package registry or repository. In non-human identity terms, it is privileged operational access, because whoever controls it can alter downstream software that many systems trust automatically.
• Workflow Runner Persistence: Workflow runner persistence is the ability of an attacker to retain access through CI/CD automation infrastructure after the original package or script is removed. It matters because runners can preserve identity and execution paths beyond the lifespan of a single job.
• Identity Blast Radius: Identity blast radius is the amount of downstream damage one credential, token, or account can create when its permissions are reused across systems. In this article's context, it measures how far a compromised maintainer can spread malicious code and secret exposure through package ecosystems.

What's in the full article

Knostic's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of the two-stage payload and why Bun-based execution evades common detection paths
• Indicators of compromise such as repository naming patterns, workflow changes, and package markers tied to propagation
• Defensive actions for npm, GitHub, and CI/CD environments, including rollback and rotation sequencing
• Observed scale data across compromised packages and infected repositories, useful for incident scoping

👉 Knostic's full post covers the attack chain, propagation mechanics, and immediate defensive actions.

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.