What you need to know

• Shai-Hulud is an npm-delivered, self-propagating worm that steals developer, CI/CD, and cloud credentials, then uses the victims’ own accounts to spread further.
• A new “Second Coming” wave (also called Shai-Hulud 2.0 or Sha1-Hulud) kicked off around 21–24 November 2025 and is still ongoing as of this writing. It has compromised roughly 600–800 npm packages and more than 25,000 GitHub repositories, including popular libraries from Zapier, ENS Domains, PostHog, Postman, and AsyncAPI.
• The new variant runs during npm’s preinstall phase using setup_bun.js and bun_environment.js, installs the Bun runtime, harvests secrets with TruffleHog, and can persist by registering the host as a GitHub Actions runner named SHA1HULUD.
• If it cannot propagate or exfiltrate data, Shai-Hulud 2.0 may shred the user’s home directory, effectively acting as a wiper for developer and build environments.

Immediate steps to take if you are affected

1. Freeze npm dependency updates for high-risk projects until you finish triage and pin known-good versions using lockfiles.
2. Check for indicators of compromise (IoC):
   
   • New package files: setup_bun.js, bun_environment.js, unexpected preinstall scripts.
   • Suspicious public GitHub repos in your org or user accounts with descriptions mentioning “Shai-Hulud” or “Sha1-Hulud: The Second Coming”.
   • Unknown self-hosted runners named SHA1HULUD or similar.
   • Unexpected workflow files such as .github/workflows/discussion.yaml or shai-hulud-workflow.yml.
3. Assume that any developer, CI, or cloud credentials present on affected hosts are compromised – revoke and rotate them, especially GitHub personal access tokens (PATs) and cloud keys.
4. Rebuild infected developer machines or runners from clean images rather than trusting in-place cleanup.

The rest of this post gives a condensed look at how we got here, what’s different in the current wave, and how to respond.

How we got here: The first Shai-Hulud wave

The first Shai-Hulud campaign surfaced in mid-September 2025 as a novel worm in the npm ecosystem (named after the sandworms of Arrakis from Frank Herbert’s “Dune”). Attackers compromised npm maintainer accounts using phishing and stolen credentials and then pushed trojanized versions of legitimate packages to the official registry to spread the infection. One of the most-used packages affected was @ctrl/tinycolor (around 2 million weekly downloads).

This first wave already looked like a supply-chain nightmare:

• Malicious bundle.js payload: Approximately 3.6 MB of minified JavaScript was added to compromised packages and executed via a postinstall script.
• Credential harvesting at scale: The worm used tools like TruffleHog to trawl filesystems and environment variables for high-entropy secrets, including npm tokens, GitHub PATs, and major cloud provider keys, as well as SSH keys and crypto wallet data on developer machines.
• Exfiltration via GitHub: Using the victim’s own GitHub token, the malware created new public repositories (often named “Shai-Hulud”) under the victim’s account and uploaded JSON files full of stolen secrets.
• Worm-like self-propagation: If a user’s npm auth token was present, Shai-Hulud queried npm for other packages owned by that maintainer and silently published trojanized updates to up to 20 of them, thus turning maintainers into involuntary amplifiers.
• CI/CD persistence: The worm also injected malicious GitHub Actions workflows with names like shai-hulud-workflow.yml to exfiltrate secrets on every push. This allowed data leakage to persist long after the initial infection.

By the time CISA published its September 23 alert about a “widespread supply chain compromise” affecting more than 500 npm packages, thousands of credentials and secrets had already been exposed. Some online reporting has also linked about $50M in cryptocurrency theft to credentials stolen in the wake of this first wave, suggesting at least some financial motivation behind the attacks.

The current wave: Shai-Hulud 2.0 aka “The Second Coming”

The new wave, variously referred to as Sha1-Hulud, Shai-Hulud 2.0, or “The Second Coming,” surfaced around 21–24 November 2025 and is ongoing as of this writing. Multiple vendors, including GitLab, have confirmed that this is an evolved and more destructive variant of the original worm rather than a completely unrelated campaign.

Scale and impact of Shai-Hulud 2.0

While the exact numbers vary depending on the source and will continue to grow, the second wave has already surpassed the first:

• Around 600–800 npm packages have been compromised, many of them widely used.
• More than 25,000 GitHub repositories were created or polluted with stolen secrets within the first days of the campaign.
• Dozens of maintainers have been affected, with one report citing at least 350 unique npm publishers used as seed points.

High-profile affected ecosystems include npm packages associated with Zapier, ENS Domains, PostHog, Postman, AsyncAPI, and others. Some of the infected packages are used in a large proportion of cloud environments, which greatly magnifies the potential fallout. According to Wiz research, the three most popular packages affected are @postman/tunnel-agent, posthog-node, and @asyncapi/specs.

How Shai-Hulud 2.0 works

The core goals of the worm are unchanged from the first wave: harvest secrets, exfiltrate to GitHub, weaponize victims’ identities, and spread laterally via dependency updates. The mechanics of the attack, however, have evolved to improve effectiveness. Key technical characteristics of the second wave:

• Preinstall execution: Instead of running post-install, Shai-Hulud 2.0 hooks into preinstall so the malicious script runs before installation completes (even if npm install fails later).
• Bun-based execution: Each compromised package typically adds a preinstall entry such as "preinstall": "node setup_bun.js" and includes setup_bun.js and bun_environment.js (the main malicious payload). The dropper installs Bun if needed and uses it to execute the payload. With Bun being less popular than Node.js, its use sidesteps some Node-focused defenses and sandboxes.
• Broad and automated secret collection: As in the first wave, the worm uses TruffleHog to sweep for SSH keys, GitHub tokens, npm tokens, and multi-cloud credentials. Secrets are stored in JSON files, including system.json, cloud.json, and truffleSecrets.json.
• Cross-victim credential relay: If no usable GitHub token exists on the current host, the malware looks for earlier Shai-Hulud repos corresponding to previous victims, extracts tokens from those, and uses them to exfiltrate new victims’ data. This complicates cleanup since one account’s secrets may be published on other accounts.
• GitHub Actions backdoor: After exfiltration, the malware can register the victim host as a self-hosted runner against the attacker-controlled repo, typically under a recognizable name such as SHA1HULUD. Coupled with malicious workflow triggers such as discussion.yaml, this gives the attacker persistent remote code execution via normal-looking GitHub Actions activity.
• Destructive fallback: If propagation or exfiltration fails, Shai-Hulud 2.0 now has a “dead man’s switch” that, when triggered, recursively shreds files in the user’s home directory. GitLab and others have flagged this behavior explicitly as wiper-like and capable of crippling developer and CI environments.

In short, the second wave is not just another malicious package outbreak. It is a genuinely sophisticated worm that weaponizes your CI/CD and version control infrastructure against you and can delete data if you try to stop it.

Just as important as the immediate consequences is the broader downstream impact. From credential harvesting for immediate and future use to internal source code exposure and persistent data leakage from pipelines, it is likely the fallout will be extensive and long-lasting.

What to do now: Shai-Hulud remediation and prevention

The Shai-Hulud attacks rely on abusing trust relationships in your software supply chain, covering packages, tokens, CI/CD workflows, and version control systems. If you use npm in your organization, you should respond on all four fronts:

1. Triage your dependencies

• Lock and audit: Use package-lock.json or yarn.lock to identify exactly which versions you pulled and when. Cross-reference against vendor and community lists of compromised Shai-Hulud packages (starting with this list of most common packages).
• Remove and rebuild: Remove tainted versions, pin to known-good versions or alternatives, clear npm caches, and rebuild artifacts from a clean state.
• Consider temporary change freezes for high-risk services until dependency trees are fully reviewed.

2. Hunt for indicators in GitHub and CI/CD

• Search for suspicious repos: Look for unexpected public repos, especially those with descriptions referencing Shai-Hulud or Sha1-Hulud: The Second Coming or containing JSON files with environment and system data.
• Audit runners: Enumerate self-hosted runners across your org and remove any unknown or suspicious entries, particularly any named SHA1HULUD or created recently without change tickets.
• Review workflows: Protect .github/workflows with branch protection or approval rules and scan for newly added or modified workflows such as discussion.yaml or shai-hulud-workflow.yml that exfiltrate secrets or spawn shells.

3. Treat all exposed credentials as burned

• Rotate GitHub tokens, npm tokens, CI/CD secrets, and cloud keys for any account that installed or built with compromised packages, including developer workstations, CI runners, and shared build agents.
• Where possible, replace long-lived tokens with short-lived, scoped credentials and enforce MFA on npm, GitHub, and cloud accounts.

4. Contain and rebuild compromised machines

• Assume full environment compromise if Shai-Hulud ran on a host. That includes all files in the user’s home directory and any secrets reachable from that machine.
• Reimage developer laptops and self-hosted runners instead of attempting surgical cleanup only. The presence of a wiper routine is a clear signal that you should not trust the remaining state.

5. Harden your supply chain for the next wave

• Sandbox installs: Run npm install in isolated containers with no access to real secrets, especially for unpinned or newly introduced dependencies.
• Use automated scanning: Combine software composition analysis and supply-chain-focused scanning to flag malicious or anomalous packages before they reach production.
• Enforce workflow protections: Require reviews for workflow changes, maintain an allow-list of runners, and monitor for unexpected GitHub Actions activity across repos.
• Maintain SBOMs: Keep SBOMs and dependency tracking in place so you can quickly answer the question: “Were we running this specific version when the worm hit?”

Conclusion: Sandworms burrow deep

As if the tech industry needed another reminder about the fragility of the supply chains underpinning much of today’s software, Shai-Hulud shows how quickly one precision strike can turn trusted tooling into an attack surface all of its own. The immediate job is triage and cleanup, but the long-term lesson is also clear: treat npm packages, CI/CD workflows, and developer machines as part of the same supply chain and secure them accordingly. 

And that’s because no matter if Shai-Hulud rears its head again in the future, similar supply-chain attacks are only a matter of time.