Shai‑Hulud Worm Strikes: npm Supply‑Chain Chaos

On Nov. 24 a nasty little worm named Shai‑Hulud (yes, stage‑y naming is back) staged a second wave of supply‑chain mischief across the npm registry. Security researchers at Aikido spotted the activity early morning UTC and found that nearly 492 packages — together pulling in roughly 132 million monthly downloads — were tainted. Big developer ecosystems like AsyncAPI, PostHog, Postman, Zapier and ENS felt the burn.

What happened (short and spicy)

The worm arrives as poisoned package updates. During install it drops a JavaScript setup that pulls in the Bun runtime and then runs a payload that hunts for secrets in developer environments using TruffleHog-style scanning. When it finds tokens, API keys or npm/GitHub credentials, it publishes them to newly created public repositories — the attacker even labeled those repos with the theatrical description “Sha1-Hulud: The Second Coming.”

This November campaign cranked up the scale: the malware tries to push infected versions into up to 100 other packages, and it now generates randomly named repositories for stolen data (handy for them, annoying for defenders). The payload lives in files like setup_bun.js and bun_environment.js inside the compromised packages. The worst bit: if stolen credentials fail to authenticate, some builds now try to nuke the user’s home directory. Yikes.

Luckily for everyone, the worm wasn’t flawless. Researchers found bundling bugs that sometimes copied only the Bun installer and left out the actual malicious payload, which limited propagation in places. Still, the initial hits included high‑value targets — dozens of AsyncAPI releases, multiple PostHog modules, Postman packages, Zapier tooling and several ENS packages — so exposure was significant.

There’s also evidence the attacker did more than just hijack tokens: AsyncAPI discovered a malicious branch in their CLI repo that contained a deployed version of the malware, implying the intruder had write access to source repos in at least some cases. That tactic — altering source repositories to poison legitimate build pipelines — has shown up in previous supply‑chain incidents and it’s especially dangerous.

What to do right now (if you breathe code)

If your org used any packages from the affected ecosystems or updated/install packages after Nov. 24, assume compromise until proven otherwise. Practical triage steps:

– Audit dependencies from the impacted ecosystems and identify any installs or CI runs that used those packages after Nov. 24.

– Rotate anything that might have been exposed: GitHub tokens, npm credentials, cloud keys, CI/CD secrets and API keys. Treat them as compromised if they were used on machines that installed the infected packages.

– Search your repos and CI logs for the string “Sha1-Hulud: The Second Coming” and for any suspicious new public repositories created from your environment. The stolen credentials were often dumped into public repos, so look for them early.

– Disable npm postinstall scripts in CI pipelines to stop install‑time execution of arbitrary code. Use lockfiles and pin package versions so sudden malicious releases can’t sneak in as easily.

– Investigate any repository write access controls. If upstream source repos were modified, rotate keys, audit collaborators, and force a review of commits and branches created around the incident windows.

Final takeaway: this was a reminder that supply‑chain attacks are messy and creative. Patch your secrets, harden CI, and maybe avoid installing random packages at 3 AM unless you enjoy drama.