Shai-Hulud 2.0: What the Second Coming of the npm Worm Really Taught Us

At the end of November 2025, the Shai-Hulud malware came back in a big way.

What started as “just another npm incident” quickly turned into one of the most aggressive software supply-chain attacks we’ve seen so far: hundreds of compromised npm packages, tens of thousands of GitHub repositories, and hundreds of thousands of secrets exposed across cloud, CI/CD, and developer environments.

By early December, the initial wave had already passed, but the story was — unfortunately — not over. Shai-Hulud 2.0 is a great (if painful) case study in how fragile our build pipelines still are.

This post pulls together what’s happened so far and, more importantly, what engineering teams should be doing about it now.

A quick recap: from v1 to “The Second Coming”

The first Shai-Hulud campaign hit the npm ecosystem earlier in 2025, compromising a smaller number of packages and a few hundred repositories before it was contained. 

In late November, researchers spotted a second wave, now dubbed Shai-Hulud 2.0 or “The Second Coming”:

• Around November 21–24, 2025, attackers began compromising maintainer accounts and republishing trusted npm packages with malicious install-time scripts.
  

• In the span of just a few hours, the worm managed to backdoor hundreds of npm packages and propagate into more than 25,000 GitHub repositories, with later estimates pushing that figure beyond 30,000.
  

• High-profile organizations such as Zapier, Postman, PostHog, and projects in the Ethereum Name Service (ENS) ecosystem discovered trojanized packages in their namespaces, though most reported no compromise of their core SaaS platforms.

By the time many teams woke up to the incident, their CI jobs had already pulled and executed the malicious versions.

How Shai-Hulud 2.0 actually works

From a distance, Shai-Hulud is “just” another dependency hijack. Under the hood, it’s closer to a worm designed for cloud-era development.

1. Compromised tokens → trojanized packages

The campaign is powered by stolen npm and GitHub tokens. Attackers use those credentials to:

1. Republish existing, legitimate packages under the same name and version range.

2. Add a malicious preinstall or other lifecycle script to the package.json.
   

Because the packages come from the original namespace, they look perfectly benign in package.json and lockfiles.

2. Bun-based payload and self-replication

Shai-Hulud 2.0 has a two-stage execution flow:

• It fetches and installs the Bun runtime through a script commonly named setup_bun.js.

• It then executes bun_environment.js, which contains the core malicious logic.
  

This payload:

• Scans the environment for credentials and secrets (cloud keys, GitHub tokens, CI/CD tokens, API keys, etc.).

• Exfiltrates them by pushing commits to GitHub repositories controlled by the attackers.

• Uses any newly stolen tokens to infect additional packages and repositories, allowing the worm to spread laterally across organizations and ecosystems.
  

3. Public GitHub repos as a data exfil API

Instead of a traditional C2 server, Shai-Hulud 2.0 uses public GitHub repositories as its “drop box”:

• Stolen secrets are committed directly into attacker-controlled repos, often via automatically created repos that look like personal scratchpads or random projects.

• Some repos use descriptions like “Shai-Hulud: The Second Coming” or slight variations, though newer iterations have begun using more generic naming to evade simple searches.
  

This makes detection trickier: there’s no suspicious outbound IP to block; everything looks like normal Git operations.

4. A wiper-flavored failsafe

According to analysis by Palo Alto Networks’ Unit 42 and other security teams, the malware includes a destructive fallback mechanism: if it cannot authenticate with GitHub or NPM, or fails to exfiltrate data, it may attempt to securely overwrite and delete every writable file in the user’s home directory, acting as a punitive sabotage rather than pure credential theft.

So even if your secrets are relatively safe, a failed infection can still cause serious damage to developer workstations or build agents.

How bad did it get? (Spoiler: pretty bad)

We still don’t have a perfect global picture, but by early December 2025, several independent analyses lined up to paint a similar story:

• 796–800+ npm packages were confirmed as backdoored by Shai-Hulud 2.0, collectively seeing tens of millions of weekly downloads.

• Over 25,000 GitHub repositories were initially reported as contaminated, with later figures pushing the estimate past 30,000 repos as the campaign continued to unfold.

• BleepingComputer reported that up to 400,000 unique secrets may have been exposed in those repos, though many of them are thankfully expired or low-impact.
  
  

The real impact lies not just in the raw numbers, but in where those secrets came from:

• CI/CD systems (GitHub Actions, GitLab CI, etc.)

• Cloud platforms like AWS, Azure, GCP, and others

• Internal tooling tokens and API keys

• Personal access tokens for GitHub and npm

Even if only a small fraction of those secrets is still valid, that’s a huge amount of potential access for future attacks.

The aftermath: still active, just slower

So what’s changed between the end of November and early December?

• The peak is over, but the worm is not dead.
  Analyses from Wiz and others around December 1–3 show that the explosive growth phase is behind us, but new infected repos and package versions are still being observed — just in smaller bursts instead of thousands per hour.

• Tail-risk from CI and automation.
  Old CI pipelines and developer environments that haven’t been cleaned up are still pulling vulnerable versions, continuing to re-infect environments even after npm removes malicious packages from the registry. 

• Cross-ecosystem hints.
  Researchers spotted at least one Maven package (org.mvnpm:posthog-node:4.18.1) that embedded the Shai-Hulud payload, suggesting the operator is experimenting beyond npm. 

Put differently, the incident has moved into the “long tail” phase. If your team hasn’t done any proactive response yet, the risk is very much still real.

Why search engines won’t save you (and what this means structurally)

There’s a temptation to see incidents like this as a one-off: “a few bad packages slipped through, let’s patch and move on.”

Shai-Hulud 2.0 highlights some deeper issues:

1. Developers and CI systems are now high-value initial-access targets.
    The goal is less “hack Company X directly” and more “hack the tools used by everyone building anything.”
   

2. Our dependency graphs are too big to reason about manually.
    Hundreds of compromised packages, thousands of dependents, tens of thousands of repos — no human review process scales to that. Automated SBOMs, dependency monitoring, and runtime checks are no longer optional.
   

3. Secrets sprawl is the real breach.
    The main payload is a credential stealer. Source code infections are painful, but the long-term risk comes from leaked tokens that can be used weeks or months later.
   

4. Registry cleanup isn’t enough.
    npm and GitHub moved quickly to remove malicious packages and repos, but by then, artifacts were already pulled into caches, lockfiles, internal registries, and CI images.
   

From a security and engineering-leadership perspective, the lesson is simple: your build pipelines and dev environments are production. Treat them that way.

A practical Shai-Hulud 2.0 checklist for engineering teams

Here’s a concrete set of steps you can adapt into your incident-response playbook or internal advisory.

1. Identify if you pulled compromised packages

• Export your dependency lists / SBOMs from package managers, lockfiles, and internal registries.

• Cross-reference them against public indicators of compromise (IoCs) and package lists published by vendors and research teams (Wiz, Datadog, Check Point, etc.).

• Don’t forget transitive dependencies: many infected packages were not top-level dependencies but came in indirectly.

If you find a match, assume that any machine or CI runner that installed those versions is potentially compromised.

2. Rotate secrets aggressively

If there’s one non-negotiable step, it’s this.

For every environment that touched infected packages:

• Rotate cloud credentials (IAM users, roles, service accounts).

• Rotate CI/CD tokens (GitHub Actions, GitLab, CircleCI, etc.).

• Rotate npm and GitHub PATs/org tokens.

• Invalidate or rotate internal API keys and application secrets used by those agents.

Treat every long-lived secret as burned unless you have strong evidence otherwise.

3. Hunt for suspicious Git activity

Because Shai-Hulud 2.0 uses GitHub repos for exfiltration, you should:

• Look for unfamiliar repositories under your org or users, especially those created recently with odd names or references to “Shai-Hulud” / “Second Coming”.

• Review audit logs for:

• Unexpected pushes from CI runners to repos you don’t recognize

• Repo creation and deletion spikes during the incident window

Even if the malicious repos have been removed by GitHub, your internal logs can still show that something happened.

4. Harden your npm and CI workflows

Going forward:

• Disable or heavily restrict lifecycle scripts (preinstall, postinstall) in CI unless explicitly required. Many build systems allow you to block or sandbox these.

• Enforce MFA and trusted publishing for npm maintainers and GitHub org admins. This is especially important ahead of npm revoking classic tokens (currently scheduled around December 9, 2025). 

• Introduce an allow-list for internal registries so that only approved packages/versions can be installed in CI.

• Run static and dynamic scanning on build images and runners, not just the application code.

5. Improve runtime visibility

Assume you will miss the next one at the dependency level.

To limit blast radius:

• Deploy runtime monitoring that can flag:

• Unusual process trees on build agents (e.g., npm → node → bun unexpectedly).

• Unexpected outbound network traffic from CI runners or dev machines.

• Anomalous Git operations (new repos, pushes to unknown repos from CI).

• Set up alerts for large numbers of new repos or tokens created in a short period — a behavior that lined up with the worm’s spread.

What to tell your team (and your leadership)

If you need to explain this incident internally in one slide, you could phrase it like this:

Shai-Hulud 2.0 is a worm that spread through compromised npm packages, stole secrets from CI/developer environments, and dumped them in GitHub repos. It hit ~800 packages, ~30k repos, and exposed up to ~400k secrets. Even though the initial wave has slowed, any pipeline that installed those packages should be treated as compromised.

From there, the key messages are:

• We’re rotating secrets and auditing dependencies now.

• We’re hardening our CI and package workflows so that the next worm has a smaller blast radius.

• We’re treating dev and CI environments as production security assets.

Closing thoughts

Shai-Hulud 2.0 won’t be the last supply-chain worm to hit npm — or any other ecosystem. In some ways, it’s a preview of what “normal” looks like when your entire industry builds on shared registries, shared CI platforms, and shared collaboration tools.

If you’re writing or maintaining software in 2025, this incident isn’t just a news item; it’s a design requirement:

• Secrets must be short-lived, scoped, and easy to rotate.

• Build systems must assume compromised dependencies and still be resilient.

• Security controls must extend to developer and CI environments, not just production.

If you turn this incident into a forcing function to clean up your secrets, tighten your pipelines, and improve your visibility, Shai-Hulud 2.0 will still have been painful — but at least it won’t have been wasted.