In September I published an article about the NPM incident and why the initial exploit is only the starting point of an attack.
That attack was targeted and fairly straightforward. A maintainer was phished, a few packages were poisoned, and the goal was limited to stealing crypto.
Shai-Hulud takes a very different approach. It doesn’t rely on a victim clicking anything and it doesn’t stop at the initial machine it lands on. Instead, it uses the trust built into the software ecosystem to move from one environment to the next. In doing so, it turns the supply chain itself into a distribution network.
A Worm Hidden In Plain Sight
Wiz Research just published an excellent breakdown of the technical behaviors behind Shai-Hulud, here is a quick recap of how this worm works in practice:
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. To the system, Bun looks like another developer tool. To the attacker, it is a quiet lane with far fewer controls.
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.
As Dmitriy put it during the podcast we recorded on Shai Hulud: “It’s like broadcasting stolen intel over public radio.”
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 scales from a handful of packages to hundreds.
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 and durable 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.
The Deeper Issue: Supply Chains Spread Trust Faster Than Defenders Can Monitor It
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.
Seeing The Worm Through Behavior, Not Signatures
Modern supply-chain attacks reveal themselves through patterns of activity rather than static indicators. Shai-Hulud leaves signals such as:
- A GitHub token creating dozens of repos out of nowhere
- A CI runner reading cloud secrets at a volume that doesn't match its job
- A workstation suddenly running a new automation runner
- A cloud key using services it has never touched
- A machine uploading large amounts of data to GitHub
Each action is ordinary. The sequence is not. This is where Vectra AI ties into the story. The platform doesn’t try to block package installations. It watches what happens after code runs, across identity systems, networks, and cloud environments. It correlates unusual account activity, unexpected data movement, and cloud actions that don’t fit established patterns. That context helps security teams see the full attack chain instead of a scattering of isolated events. And in supply-chain incidents like Shai-Hulud, context is everything.
If you want to see how the Vectra AI platform works in practice, you can explore it in our self-guided demo.