Shai Hulud 2.0
Hi, I’m Mike Broomfield, an experienced cybersecurity leader with around 20 years of hands-on experience spanning consultancies, global financial institutions, and large-scale enterprises. My career has taken me from penetration testing and security architecture roles at leading consultancies and major banks to my current position as Head of Application Security & Security Testing at Tesco. I have a deep passion for security research and engineering innovation, with a focus on embedding security seamlessly into modern software delivery. Over the years, I’ve led initiatives that integrate security into CI/CD pipelines, automate developer guardrails, and strengthen the resilience of complex, cloud-native systems. My approach blends a developer-first mindset with a curiosity for how systems fail and how they can be built stronger.
The first Shai-Hulud campaign surfaced in mid-September 2025 as a novel worm in the npm ecosystem (named after the sandworms of 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).
The new wave, variously referred to as Sha1-Hulud, Shai-Hulud 2.0, or “The Second Coming,” surfaced around 21–24 November 2025. Multiple vendors have confirmed that this is an evolved and more destructive variant of the original worm rather than a completely unrelated campaign.
I thought as a follow-up to my last article on open source software supply chain attacks, this would be a perfect example for analysis.
How Shai-Hulud 2.0 works
The core goals of the worm are unchanged from the first wave: harvest secrets, exfiltrate to GitHub, weaponise victims’ identities, and spread laterally via dependency updates. The mechanics of the attack, however, have evolved to improve effectiveness.
1. Installation becomes execution
The moment a developer or CI pipeline installs an infected package, the payload runs automatically. There is no prompt or obvious indicator that anything unusual is happening. The worm hides inside routine build steps, which is why the initial execution goes unnoticed.
2. It steps around common security controls by switching runtimes
Most JavaScript development relies on Node.js, the engine behind npm and the one most teams monitor. Security tooling, logging, and scanning are built around Node.
Shai-Hulud avoids this by downloading and running its payload with Bun, a newer, high-performance runtime that isn’t commonly monitored. This simple runtime shift helps the worm bypass many of the guardrails teams expect to rely on.
3. It collects any access it can find
Once running, the malware systematically searches for access. It looks for:
NPM tokens
GitHub credentials
CI/CD secrets
API keys
Cloud credentials from metadata services
Developer laptops, build servers, and cloud machines are treated the same. If a system has access, the worm collects it.
4. It leaks the stolen data in public by design
Instead of sending data back to a command-and-control server, the worm creates public GitHub repositories under the victim’s account and uploads the stolen secrets there. This eliminates the need for hidden infrastructure and leaves sensitive credentials exposed to anyone who knows where to look.
5. It spreads using the victim’s existing trust
If a compromised maintainer manages several packages, Shai-Hulud republishes malicious versions across all of them. If a GitHub token gives access to multiple repositories, those repositories become the next injection points. The worm grows by riding the trust the victim already has in the ecosystem. That’s how it scaled from a handful of packages to hundreds in such a short time.
6. It plants a persistent backdoor through GitHub Actions
The malware installs a self-hosted GitHub Actions runner on the victim’s machine and drops a workflow that triggers whenever someone opens a GitHub Discussion. This gives the attacker a quiet foothold.
Commands executed through a discussion thread run directly on the compromised system while blending in with normal automation.
7. It carries a wiper for destructive fallback
Under certain conditions, the malware can wipe files from the host. Not every environment would trigger this, but the capability adds another layer of risk: the attack isn’t limited to theft; it also has the potential to disrupt development entirely.
Everything Shai-Hulud does aligns with normal development and automation workflows:
installing dependencies
running scripts
publishing packages
talking to GitHub
querying cloud APIs
None of these behaviors are suspicious on their own. They are everyday operations.
This is what makes the worm effective. It doesn’t behave like malware. It behaves like development, and it relies on the trust that development workflows inherit by default:
Developer machines hold long-lived tokens
CI pipelines run code automatically
Cloud roles carry broad permissions
Source control acts as both collaboration platform and automation engine.
Shai-Hulud simply follows the trust.
Conclusion
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.
