Shai-Hulud 2.0 Supply-Chain Worm - Deep Dive into the November 2025 NPM Crisis

Overview

Shai-Hulud 2.0 is the latest and most aggressive iteration of the self-propagating worm that first surfaced in September 2025. This second wave - dubbed “The Second Coming” by attackers - represents a major escalation in both scale and sophistication. Between November 21 and November 24, 2025, attackers compromised hundreds of NPM publisher accounts and trojanized dozens to hundreds of widely used packages. The worm now targets not just end-user installations but developer environments and CI/CD pipelines, harvesting credentials, exfiltrating secrets, and propagating across GitHub repositories and package registries at an alarming pace.

How the Attack Unfolded

The campaign begins when a developer installs a compromised NPM package. In Shai-Hulud 2.0, malicious payloads are embedded via pre-install lifecycle scripts (in package.json), which triggers execution even before installation completes. The script deploys a dropper (setup_bun.js) that installs a less-monitored runtime environment (Bun) if not already present. Using this runtime, the worm launches an obfuscated payload (bun_environment.js) that runs as a detached background process to avoid detection.

Once running, the malware scans its environment for sensitive information - including NPM tokens, GitHub PATs, cloud provider credentials (AWS, GCP, Azure), CI/CD secrets, environment variables, and metadata-service keys. If it finds GitHub access, it creates public repositories under the victim’s account (e.g. named “Shai-Hulud”) and uploads the stolen secrets, often in encoded or obfuscated form.

Simultaneously, the worm abuses stolen credentials to republish compromised versions of other NPM packages maintained by the victim. This allows it to propagate substantially - turning a single compromised developer into a node that infects multiple packages, developer environments, and downstream projects. In some cases, the worm also injects malicious GitHub Actions workflows and migrates formerly private repositories into public or attacker-controlled spaces, turning the entire supply chain into a distribution network.

Scale and Impact

By the time of the second wave’s detection, Shai-Hulud 2.0 had trojanized approximately 796 unique NPM packages - many of them widely used libraries - and impacted more than 25,000 GitHub repositories. The packages affected include modules from recognized organizations and popular projects, including integrations used by major platforms and CI/CD environments.

The breadth of the compromise is considerable: cloud-native applications, developer environments, build servers, and CI/CD pipelines may all be vulnerable if they incorporated an infected package at any point. Credential theft alone is massive: hundreds of GitHub tokens and thousands of cloud credentials may have been exposed, potentially granting attackers persistent access to source code, deployment environments, and cloud infrastructure. The propagation mechanism means that even projects not directly depending on the original compromised packages can become infected if they relied on a compromised maintainer’s modules or used shared dependencies.

Moreover, Shai-Hulud 2.0 introduces destructive potential: some payload variants include a “dead-man switch” or fallback wiping behavior, meaning that failure to propagate or exfiltrate could lead to erasure of developer environments - potentially destroying local source trees, environment configurations or build artifacts. This raises the risk from pure data theft to outright sabotage and supply-chain disruption.

Tactics, Techniques & Evolution

Compared to the initial September 2025 wave, Shai-Hulud 2.0 shows several notable advancements. First, it shifts execution from Node.js to Bun - a lesser-monitored runtime - thereby bypassing many security tools tuned to Node. This evasion makes detection harder and increases the likelihood of unnoticed infiltration.

Second, exfiltration no longer depends on ephemeral webhook endpoints; instead the worm writes stolen secrets directly into GitHub repositories owned by victims. This open-repository method is stealthy, persistent, and harder to block once given legitimate credentials. Additionally, the worm now targets CI/CD pipelines and cloud credentials, widening its operational scope beyond developer machines.

Finally, the worm’s propagation mechanism leverages the very trust developers place in package maintainers and widely used libraries. By compromising maintainer accounts, attackers gain the ability to inject malicious versions across many packages, which downstream projects automatically consume - creating a chain reaction that quickly spans the open-source ecosystem.

Response and Remediation Efforts

Since the public disclosure of the 2.0 wave, major registry maintainers, security vendors, and platform providers have mobilized to contain the damage. Malicious package versions have been flagged and removed by NPM maintainers; GitHub is deleting attacker-created repositories and revoking compromised tokens; security tools and supply-chain scanners (SCA) are being updated with signatures and heuristics to detect Shai-Hulud artifacts.

Organizations are urged to audit their dependency trees, purge any potentially compromised packages, clear caches (e.g. npm cache), reinstall dependencies from trusted sources, and rotate all credentials - including GitHub PATs, NPM tokens, SSH keys, and cloud credentials. Developers and CI/CD administrators are also recommended to disable or restrict preinstall and postinstall scripting, enforce multi-factor authentication (MFA) on developer accounts, and monitor unusual GitHub activity (new repos, unexpected public releases, workflow additions).

More advanced mitigations involve implementing software supply-chain security tools (SBOM generation, policy-based blocking of unknown/untrusted packages, automated dependency auditing), network-level controls to restrict outbound connections during build/install phases, and behavioral monitoring of dev-endpoints and CI runners for anomalous activity - such as unexpected runtime downloads or unusual repository creation patterns.

Wider Implications for the Software Ecosystem

Shai-Hulud 2.0 marks a new milestone in supply-chain attacks - one where malicious code does not need central command-and-control infrastructure, but propagates automatically via trusted development workflows. It exposes how deeply integrated and fragile modern software supply chains are: a single compromised maintainer account can cascade into thousands of infected downstream projects, stolen credentials, contaminated build artifacts, and massive cloud exposure.

This incident underscores the urgent need for organizations to treat open-source dependencies and development tooling as part of their attack surface - not just production or runtime environments. Traditional perimeter defenses and runtime monitoring are insufficient; security must extend upstream into developer environments, build pipelines, cloud credential management, and package trust boundaries. The future of secure software development will increasingly depend on supply chain hygiene, continuous auditing, immutable infrastructure, and zero-trust approaches to dependencies and external packages.

Indicators of Compromise

• Trojanized NPM packages with pre-install scripts that trigger setup_bun.js and execute bun_environment.js payloads.
• New GitHub repositories created under developer accounts with names referencing “Shai-Hulud” (e.g. “Shai-Hulud”, “Shai-Hulud Migration”) containing encoded secrets files such as data.json, environment.json, cloud.json, or truffleSecrets.json.
• Unexpected GitHub Actions workflows added to repositories, especially workflows named like “shai-hulud-workflow.yml” or similar, often automatically triggered by repository creation or CI events.
• Out-of-band credential leaks: exposed GitHub tokens, NPM tokens, cloud provider credentials (AWS, GCP, Azure), CI/CD secrets, API keys, environment variables, and metadata-service keys in public repos or logs.
• Automated republishing of known packages by previously compromised maintainer accounts - new versions appearing shortly after compromise, especially versions published between November 21–23, 2025.
• Unusual runtime download during package install (e.g. download and installation of Bun), unexpected external network connections during npm install or CI jobs, or suspicious post-install behavior deviating from typical package installation flows.