Shai-Hulud 2.0: A Technical Breakdown and Why Secrets Need to Die

What Actually Happened - A Technical Postmortem

In November 2025, threat actors relaunched Shai-Hulud, calling it "The Second Coming." This version is significantly more aggressive, infecting hundreds of npm packages and digging deep into developer machines and CI runners. Here's the flow, in plain technical terms:

1. Compromised npm Packages

Multiple popular npm libraries were hijacked (Zapier SDK, AsyncAPI specs, PostHog SDKs, Postman and others). The attacker added a malicious preinstall hook to each package.json. That means:

• The payload runs before the package is even installed.
• It executes whether you use npm, pnpm, yarn, or anything that honors lifecycle scripts.

2. Bootstrapping Through Bun

Each infected package runs a script, bun_setup.js, which:

1. Checks if Bun (a JS runtime) is installed.
2. If not, silently downloads and installs Bun.
3. Once Bun is present, executes the real payload: bun_environment.js.

This second payload is megabytes in size and heavily obfuscated.

3. Deep System Recon & Credential Harvesting

bun_environment.js does the following:

• Launches TruffleHog internally to scrape secrets from:
  • Git repos
  • Local files
  • Environment variables
  • Shell history
• Extracts cloud credentials (AWS, GCP, Azure)
• Collects npm and GitHub tokens
• Gathers metadata, environment variables, and system info

The payload works on Linux, macOS, and Windows.

TruffleHog is an open source powerful and popular secrets scanning tool

4. Worm-like Self-Propagation

The malware:

• Uses stolen npm tokens from .npmrc
• Enumerates packages the victim can maintain
• Downloads them
• Injects its own preinstall backdoor
• Publishes a new version under the victim's identity

This turns every compromised developer into a new infection source.

5. Clever Exfiltration via GitHub

Instead of talking to a suspicious server, Shai-Hulud uses GitHub as its exfiltration channel:

• Creates public repos with random names
• Uploads encoded JSON files:
  • cloud.json
  • environment.json
  • contents.json
  • truffleSecrets.json

It even registers the victim machine as a self-hosted runner and plants a malicious GitHub Actions workflow for persistence.

6. Impact at Scale

• 600+ npm packages infected
• 20,000+ GitHub repos created for exfiltration
• 15,000 leaked secrets

This is the largest npm supply-chain incident since the ecosystem existed.

Static Secrets Are the Real Vulnerability

The core issue Shai-Hulud 2.0 exploited wasn't Bun, npm, GitHub, or JavaScript. It was the industry's addiction to long-lived credentials.

Why Static Secrets Are Fundamentally Broken

1. They Don't Rotate

Tokens meant to be "temporary" end up living for months or years. Shai-Hulud 2.0 harvested npm and GitHub tokens and immediately re-used them to:

• Publish malicious package versions
• Create GitHub repos
• Push exfiltrated data

If a token doesn't expire, it will be abused.

2. Secrets Live Everywhere

Developers scatter secrets across:

• .npmrc
• Shell environment variables
• CI runner environments
• Config files
• Local Git clones

Embedding TruffleHog in malware effectively creates an automated, instant credential harvesting tool.

3. CI/CD Runners Are Gold Mines

Most CI systems expose:

• Long-lived GitHub tokens
• Cloud creds in environment variables
• Overprivileged roles like repo:write or publish

Shai-Hulud harvested them effortlessly.

4. Using GitHub for Exfiltration Makes Defense Hard

Blocking GitHub API traffic also breaks all legitimate developer workflow. So the malware blends in perfectly, under the radar.

Moving Beyond Secrets: The Identity-First Future

The solution isn't "rotate tokens faster" or "put them in a vault."

The solution is no more static secrets. Use ephemeral, identity-based access.

The Better Model:

• Short-lived credentials
• SPIFFE identity-based authentication
• Just-in-time access
• No secret material stored on disk
• Least privilege, enforced by policy
• Telemetry-rich control plane

This is the model cloud-native security should be rallying around, and this is also the model Riptides is built on.

Workloads shouldn't "have a secret."They should have an identity.

Why This Couldn't Happen With Riptides

Let’s look at the same attack path in a real application. In this demo we walk through an npm supply-chain compromise that scrapes API keys from a running pod, and then show how Riptides breaks the chain by removing static credentials and delivering them just-in-time to the right process.

Conclusion: Riptides Is What the Supply Chain Needs

Static secrets are a liability. Attackers don't break through your zero trust perimeter, they just find a token lying around and become you.

Riptides solves this by:

• Eliminating long-lived secrets
• Issuing workload identities through SPIFFE
• Enforcing least-privilege policies within the Linux kernel
• Providing kernel-level telemetry
• Delivering ephemeral identity instead of permanent power

Identity beats secrets. Riptides makes identity nativ, all the way down from the Linux kernel.

If you enjoyed this post, follow us on LinkedIn and X for more updates. If you’d like to see Riptides in action, get in touch with us for a demo.