If you run a JavaScript site, chances are you're running code you didn't write and never read. That's not a criticism — it's how the entire modern web works, from Next.js apps down to the smallest utility library. In 2025, that trust model got tested at scale by an npm supply-chain worm researchers named Shai-Hulud, and a second wave in December 2025 (sometimes called "Shai-Hulud 2.0" or informally "mini Shai-Hulud" for smaller follow-on compromises) made clear the first wave wasn't a one-off.
What actually happened
Shai-Hulud compromised more than 500 packages in the npm registry — the repository nearly every JavaScript project pulls dependencies from. The mechanism is what made it a worm rather than a one-time breach: once it compromised a developer's machine or credentials, it harvested their npm and GitHub tokens, used those stolen credentials to authenticate as that developer, injected malicious code into packages they maintained, and published the compromised versions — automatically, without further human involvement. Each newly compromised maintainer became a new launch point. The malware also went after cloud credentials directly: AWS, Google Cloud, and Microsoft Azure API keys, exfiltrated to attacker-controlled endpoints.
That's the part worth sitting with: this wasn't phishing aimed at end users, and it wasn't a vulnerability in your code. It was an attack on the supply chain that delivers your code to you — a compromised npm install could hand over your cloud credentials before you'd written a single line.
Why it matters even if you didn't get hit directly
Most sites never install a compromised package directly. They install something that depends on something that depends on the compromised package, three or four layers down, in a lock file nobody reads line by line. That's the nature of the modern dependency tree — and it's exactly why a worm that spreads maintainer-to-maintainer is so effective against it.
What we actually do about it
There's no single fix, but there is a set of habits that meaningfully lowers the risk:
- Pin dependency versions rather than accepting automatic minor/patch updates blindly, and review lock-file diffs before merging.
- Rotate credentials on a schedule, not just after an incident — tokens that never expire are exactly what a worm like this is built to harvest.
- Enforce phishing-resistant MFA on npm and GitHub accounts, since credential theft is the whole propagation mechanism.
- Turn on dependency and secret scanning (GitHub's Dependabot and secret scanning, or equivalent) so a compromised package or a leaked key gets flagged before it's exploited, not after.
- Audit what actually needs to be a dependency. Every package you add is a package someone else could compromise on your behalf. Fewer dependencies is a real security posture, not just a performance one.
None of this is exotic. It's closer to seatbelt-level hygiene than advanced security engineering — the kind of thing that costs almost nothing until the week it matters.
The larger point
Supply-chain attacks like Shai-Hulud are a reminder that "our site is secure" is a moving target, not a checkbox you tick once. If you're evaluating who builds or maintains your site, it's worth asking directly: how are dependencies pinned, reviewed, and rotated — and who's actually watching for the next one.
Sources: CISA advisory on the npm supply-chain compromise, Microsoft Security Blog on Shai-Hulud 2.0.