Shai-Hulud: Another Wave and Going Open Source

Five Months of Shai-Hulud

Here's the compressed timeline:

‍

Each wave changes payload file names, execution hooks, obfuscation methods, and C2 infrastructure. The capability set keeps expanding. But the core operation stays the same: steal credentials, propagate, exfiltrate.

What's New in the Latest Wave

TanStack and 170+ Packages Hit

On May 12, 2026, 373 malicious package versions were published across 169 npm packages — including TanStack (83 entries), Squawk (87), UiPath (66), and Mistral AI. For the first time, the campaign expanded meaningfully to PyPI with compromised versions of mistralai and guardrails-ai

Combined affected download counts: 177M+ weekly, 518M+ monthly.

New Execution Trick: Git Dependency prepare Scripts

Previous waves usedpreinstall or postinstall hooks. This wave introduced a subtler approach: the compromised packages added a Git-based optionalDependency pointing to an attacker-controlled commit. That commit contains a prepare script that executes the payload during installation.

Because it's an optionalDependency, failures are silently swallowed by npm. The malware runs, the dependency "fails" to install, and npm install completes successfully with no error output. Payload files were named to blend into the legitimate package structure.

OIDC Token Exploitation

This is the meaningful escalation. When attacker-controlled code runs inside a GitHub Actions workflow, it doesn't need to steal a long-lived npm token at all. It can use the workflow's own OIDC permissions to mint a publish token during the build and publish directly from there.

This undermines trusted publishing - the mechanism that was supposed to make supply chain attacks harder. If the malware runs inside your GitHub Actions workflow, it inherits the workflow's OIDC identity. Provenance signatures now prove that the malicious package was legitimately built by the compromised pipeline.

‍

Credential Revocation Trap

The latest variant monitors for credential revocation. If it detects that stolen tokens are being rotated, it triggers destructive actions. This is a direct evolution of the dead-man's switch from Shai-Hulud 2.0 - but now targeted specifically at incident responders trying to contain the breach.

Shai-Hulud Goes Open Source

And here's the part that changes everything.

TeamPCP has published the full Shai-Hulud source code to GitHub. Not leaked — deliberately released with deployment instructions. The repositories function as complete instruction manuals for deploying the malware. All commits are dated January 1, 2099 — deliberate obfuscation of the actual timeline.

What's included:

• Credential harvesting modules
• C2 exfiltration logic
• GitHub repository creation for stolen data
• Self-propagation across npm packages
• Hooks targeting Claude Code - executing malware when the AI coding assistant starts

Copycats are already here. At least three affiliated GitHub accounts have been identified forking the code, with one submitting pull requests to add FreeBSD support.

This is the moment the threat model shifts. Shai-Hulud is no longer a single campaign by a single actor. It's a framework. Every script kiddie with a GitHub account can now deploy their own variant with custom C2 infrastructure, custom payload names, and custom targeting logic.

The Detection Problem Nobody Wants to Talk About

Let's be honest about where this leaves defenders.

Shai-Hulud operates across at least three distinct domains.

Each domain has its own set of tools, vendors, and detection approaches:

No single vendor spans all four. The EDR vendor doesn't understand your Kubernetes topology. The supply chain scanner catches the package but can't tell you which production services consumed it. The runtime agent sees the process anomaly but doesn't correlate it to the stolen AWS key that's now being used from an IP in a different country.

And here's the uncomfortable truth: even if you had perfect coverage across all four domains, you'd still be playing catch-up. Because every Shai-Hulud wave changes the indicators:

Different file names. Different hooks. Different infrastructure. If your detection is "look for bun_environment.js in preinstall"  you caught wave 2.0 and missed everything after it.

Now that the code is open source, the variant explosion will accelerate. Someone will fork it, rename the files to webpack_config.js, change the C2 to their own domain, and none of your existing signatures will match.

The Right Question

Stop asking "how do we detect Shai-Hulud?"

Start asking "how do we detect when stolen credentials are used abnormally?"

Because regardless of which wave, which variant, which payload file name, which execution hook, which C2 domain — the attack converges on the same outcome: credentials are stolen, and then they're used. And when they're used, they're used wrong.

An AWS access key that normally makes s3:GetObject calls from us-east-1 during business hours doesn't suddenly start calling iam:CreateUser from a residential IP in Southeast Asia at 3 AM. That behavioral deviation is detectable — and it's invariant across all Shai-Hulud variants, past and future.

This is what behavioral detection (UEBA applied to cloud identity) actually solves:

• Abnormal source: Credential used from an IP, region, or ASN never seen before for that identity
• Abnormal timing: API calls outside the identity's established activity pattern
• Abnormal actions: The identity suddenly performs API calls it has never historically made
• Abnormal volume: Bulk enumeration or data access that deviates from baseline
• Impossible travel: The same credential used from two geographically distant locations within a timeframe that makes physical travel impossible

None of these detections require knowing the malware's file name, C2 domain, or infection method. They fire because the behavior is wrong — regardless of whether the credential was stolen by Shai-Hulud 2.0, a phishing email, an exposed .env file, or a variant that doesn't exist yet.

Where We Stand (Honestly)

At Stream.Security, we built our CDR platform around this exact principle: detect threats through behavioral context, not IOC matching.

Let me be direct about what we do and don't cover.

What we don't do: We don't run an agent on your MacBook. We're not an EDR. If Shai-Hulud compromises a developer's laptop during npm install, we won't detect the malware execution itself. That's your endpoint security vendor's job.

What we do: We monitor cloud control plane activity, runtime behavior in production environments (via eBPF), and identity usage patterns across AWS, GCP, and Azure. When stolen credentials are used — regardless of how they were stolen — we detect the behavioral anomaly.

Here's why this matters for Shai-Hulud specifically:

1. Credential behavior baselines (UEBA). Every identity in your cloud environment has a behavioral fingerprint: what APIs it calls, when, from where, how often. When Shai-Hulud steals an AWS key from a developer's laptop and that key is suddenly used from an unfamiliar IP to enumerate IAM roles — that's a deviation from baseline. No IOC needed. No signature update needed. The detection fires because the behavior changed.
2. Runtime detection in production. For production workloads running in Kubernetes or on EC2/GCE, our eBPF-based runtime sensors detect process anomalies, unexpected network connections, and file system modifications. If a compromised npm dependency spawns a process that connects to a C2 server during container startup — that's visible regardless of what the C2 domain is.
3. Cross-domain correlation. This is where the pieces connect. A suspicious npm install process chain in a CI/CD runner → unexpected outbound connection → new IAM API calls from an unfamiliar source → data access pattern deviation. These aren't four separate alerts. They're one investigation. CloudTwin™ connects runtime events, identity actions, network flows, and configuration changes into a unified model, so the SOC sees the full attack chain — not isolated signals.
4. Future-proof by design. This approach caught Shai-Hulud 1.0's credential exfiltration. It caught 2.0's cross-victim token reuse. It would catch the TanStack wave's OIDC token abuse. And it will catch whatever Shai-Hulud 3.0, 4.0, or the first copycat variant looks like — because the credentials will still be used abnormally.

The Uncomfortable Conclusion

The supply chain security industry has done impressive work on the detection side. Multiple vendors caught compromised packages within hours. Scanning tools continue to improve coverage. These are essential first-line defenses.

But Shai-Hulud going open source forces a strategic reckoning. When any actor can fork the code, change the indicators, and deploy a custom variant - the malware itself becomes the wrong thing to focus on. It's like trying to stop phishing by blocking individual email subjects. You'll catch some. You'll miss more.

The part that doesn't change across variants is what happens after the credentials are stolen. The attacker has to use them. And when they do, the usage pattern will deviate from the legitimate owner's baseline. That deviation is your detection surface — and it's the one surface that doesn't expire when the attacker rotates their C2 domain.

Equip your teams to detect credential abuse behaviorally. That's what catches Shai-Hulud 1.0, 2.0, the TanStack wave, and the variant that hasn't been written yet.

References

• Stream.Security — The Shai-Hulud 2.0 npm Worm: What Happened & How Stream Detected It (Nov 2025)