Shai-Hulud 2.0: The Fast-Spreading npm Supply-Chain Worm, How It Works, How to Detect It

Shai-Hulud 2.0 is a fast-spreading software supply-chain worm that trojanized hundreds of npm packages in late November 2025, stealing cloud and GitHub credentials and automatically backdooring development environments. It builds on the first “Shai-Hulud” wave from September 2025 but adds far more automation, stealth and blast radius, impacting popular projects like PostHog, Postman, Zapier and ENS Domains.


This article explains what the attack is, where the name came from, what is publicly known about the “author,” and provides detailed detection and remediation steps for developers and DevOps teams.

A link to the public list of infected npm packages is included at the end.


What Is The Shai-Hulud 2.0 Supply Chain Attack?


In November 2025, security researchers disclosed “Shai-Hulud 2.0” (also called Sha1-Hulud v2), one of the most aggressive npm supply-chain attacks ever observed. Attackers hijacked maintainer accounts, injected malicious versions into npm, and used lifecycle scripts to execute malware during installation.


Within hours, more than 700 npm packages were compromised and over 25,000 malicious GitHub repositories were created using stolen credentials. Even though npm removed most malicious versions quickly, environments that installed affected packages during the window remain at risk because secret exfiltration already occurred.


Why the Name “Shai-Hulud”? (Dune Inspiration)


“Shai-Hulud” is the name of the massive desert sandworms in the Dune universe. The attackers adopted this name voluntarily:

● Many exfiltration repositories contained the label “SHA1-HULUD: The Second Coming.”

● Security researchers used the same label to identify the campaign.


Like a worm moving underground in secrecy, the malware “tunnels” through npm packages, developer systems, GitHub workflows and cloud credentials.


Who Is Behind Shai-Hulud 2.0?


There is no confirmed attribution. Vendors such as SentinelOne note there is no public evidence linking a real person or group to the attack.


The term “author” refers only to operations of the malware itself. For example:

● Attack infrastructure sometimes included accounts with names such as “UnknownWonderer1.”

● Automatically created GitHub repositories contained references to Sha1-Hulud.


These are not confirmed identities, only operational artifacts created by the malware.


SentinelOne’s analysis:

https://www.sentinelone.com/blog/defending-against-sha1-hulud-the-second-coming/


High-Level Timeline and Impact


● November 21–23, 2025: Compromised versions of legitimate npm packages published.

● November 24, 2025: Vendors raise public alerts as the worm spreads rapidly.

● Late November: Roughly 700–800 affected npm packages identified.

● Over 25,000 malicious repositories created using stolen GitHub tokens.


Stolen secrets include GitHub PATs, npm tokens, AWS/GCP/Azure credentials and environment variables from CI/CD systems.


How the Shai-Hulud 2.0 Worm Works

  1. A victim installs a compromised npm package.

  2. A malicious preinstall script executes automatically.

  3. Two malicious files are dropped:

    • setup_bun.js

    • bun_environment.js

  4. These scripts run through the Bun runtime (installed silently if missing).

  5. The malware collects secrets from environment variables, cloud credential folders and Git helpers.

  6. Secrets are exfiltrated to attacker-controlled GitHub repositories.

  7. Stolen npm tokens are used to trojanize more packages owned by the victim.

  8. GitHub backdoors may be installed via workflows like “discussion.yaml” or unauthorized self-hosted runners.


This creates a self-replicating worm across npm and GitHub ecosystems.


Notable Affected Ecosystem Components


Major projects observed to have compromised packages include:

● PostHog (analytics libraries and tooling)

● Postman (CLI and libraries)

● Zapier SDK components

● ENS Domains libraries

● AsyncAPI tooling


The full ecosystem impact is still being analyzed by vendors.


Latest Developments (December 2025)


● Some new compromised packages continue to surface.

● GitHub has revoked tokens and locked malicious repositories.

● Cloud providers are issuing updated detection rules.

● Security tooling now includes Shai-Hulud 2.0 signatures.


Organizations are strongly encouraged to audit builds that occurred between November 21–27, 2025.


HOW TO DETECT SHAI-HULUD 2.0


(ACTIONABLE STEPS FOR DEVELOPERS AND DEVOPS)


Detection must happen across three areas:

  1. Package dependencies

  2. GitHub workflows/runners

  3. Secrets, logs and infrastructure


1. Detect Compromised npm Packages


● Compare your package.json, package-lock.json, yarn.lock, or pnpm-lock.yaml against public lists of infected packages.

● Search dependencies for suspicious lifecycle scripts, especially preinstall.

● Look for files like:

  • setup_bun.js

  • bun_environment.js


● Scan local npm cache and node_modules folders.


Public list of known compromised packages (continuously updated):

https://gist.github.com/alexgreenland/3a7aa666a37a9e71b4abf06b274278d9#file-bad-deps-txt-L12


2. Detect GitHub Exfiltration or Backdoors


Audit for:

● Unknown newly created GitHub repositories during Nov 21–27

● Repos with names or descriptions containing “Sha1-Hulud,” “Shai-Hulud” or “The Second Coming”

● Files in these repos such as:

  • environment.json

  • cloud.json

  • truffleSecrets.json


● Unauthorized self-hosted GitHub Actions runners

● Suspicious workflows:

  • .github/workflows/discussion.yaml

  • Workflows that export secrets or modify settings


3. Detect Suspicious Cloud and CI/CD Behavior


Check AWS CloudTrail, GCP Audit Logs, Azure Activity Logs for:

● Unexpected secret-manager access

● Credential dumps

● Role escalations

● Activity from CI runners outside normal patterns


In CI/CD logs, look for:

● Downloads of external runtimes during npm install

● Sudden creation of JSON files containing secrets


HOW TO FIX AND CLEAN UP


(FOR DEVELOPERS)


Step 1: Stop All Builds Using Suspicious Packages


Temporarily stop CI pipelines and local installs until dependencies are verified safe.


Step 2: Purge Malicious Packages and Clean Your Machine


● Delete node_modules

● Clear npm cache:

npm cache clean –force

● Reinstall dependencies only after verifying package versions are clean.


Avoid reinstalling packages published between Nov 21–27 unless verified safe.


Step 3: Audit Local Repositories


Search for:

● setup_bun.js

● bun_environment.js

● discussion.yaml

● environment.json

● cloud.json


Check .git history for unauthorized workflow changes.


Step 4: Rotate Personal Credentials


You must rotate:

● GitHub PATs

● SSH keys

● npm tokens

● Cloud credentials (AWS, GCP, Azure)


Enable MFA everywhere.


Step 5: Rebuild From Clean Sources


Perform fresh clean builds after ensuring dependency chain and credentials are safe.


HOW TO FIX AND CLEAN UP


(FOR DEVOPS / PLATFORM TEAMS)


Step 1: Organization-Wide Dependency Inventory


Use SCA tools or scripts to list all npm dependencies per service.

Cross-reference with known bad package lists.


Step 2: Clean and Rebuild Affected Services


● Delete caches and remove malicious versions from internal registries.

● Force reinstall from verified clean versions.

● Rebuild and redeploy services.


Step 3: Global Credential Rotation


Rotate at scale:

● GitHub org tokens

● CI/CD runner tokens

● npm publishing tokens

● Cloud IAM keys


Move to short-lived, scoped tokens wherever possible.


Step 4: Harden GitHub and CI/CD


● Remove unknown self-hosted runners

● Delete malicious workflows

● Enforce restricted GitHub Actions permissions

● Block npm lifecycle scripts in CI:

npm config set ignore-scripts true


● Restrict outbound network access from runners.


Step 5: Cloud Incident Response


Check for:

● New high-privilege roles

● Secret manager downloads

● Suspicious EC2/Docker escalations


Rebuild any suspicious hosts from trusted images.


Step 6: Implement Continuous Supply-Chain Monitoring


Integrate SCA, EDR, cloud security tools and IoC monitoring to automatically detect new variants of Shai-Hulud.


Final Thoughts


Shai-Hulud 2.0 is not just another malicious package. It is a fully automated supply-chain worm engineered to steal secrets, propagate through npm, and gain persistent access through GitHub and cloud environments.


Any organization using JavaScript, npm or GitHub Actions should treat this as a high-urgency incident.

Start with dependency audits, environment scans and complete credential rotation. Strengthen your supply-chain processes now to prevent the next wave.


Link to public list of compromised packages:

https://gist.github.com/alexgreenland/3a7aa666a37a9e71b4abf06b274278d9#file-bad-deps-txt-L12


This blog was created with the assistance of AI.

Comments

Popular posts from this blog

Salt Wars: Iodized Salt vs. Himalayan Pink Salt – Which One Should You Use?

Why Are Fewer People Believing in God? A Shift in Faith and What It Means

The Bible Talks About Sex— But Not the Way Some Priests Want You to Believe