Shai-Hulud malware infects 500 npm packages, leaks secrets on GitHub

 There is new research that shows that hundreds of trojanized versions of well-known packages have been planted in the npm registry in a new Shai-Hulud supply-chain campaign. Which is of course, really, really bad.

Ensar Seker, CISO at SOCRadarhas provided the following comment: 

“This campaign marks a dramatic escalation in software supply‑chain threats. Unlike earlier attacks that compromised only a handful of packages or relied on drop‑in malicious dependencies, Shai‑Hulud is a self‑propagating worm that abuses developer workflows, steals developer/CI CD credentials, publishes them to public GitHub repositories, and then uses those credentials to infect additional packages. 

What makes it especially pervasive is that it targets npm packages with multi‑million download counts, packages such as @ctrl/tinycolor, Zapier, ENS Domains, PostHog and Postman have been impacted.  Through the injection of malicious scripts (often via lifecycle hooks like postinstall/preinstall) and hidden GitHub Actions workflows, the attacker turns every infected developer workstation and CI runner into a distribution node. 

To defend against this kind of attack, dev and security teams must treat npm package management and CI/CD pipelines as part of the threat surface. This means enforcing strict token/scoped access policies, limiting or auditing lifecycle scripts (especially preinstall/postinstall hooks), monitoring secrets in build environments and using behavioral analytics to detect unusual GitHub Actions workflows or outbound connections from build hosts. Given the worm‑like nature of Shai‑Hulud, time is of the essence: any delay in rotating tokens or cleaning compromised build agents can lead to rapid spread.

In short, Shai‑Hulud isn’t a typical “package compromise”; it’s a worm embedded into the dev supply chain. It signals that attackers are shifting from targeting compiled binaries and runtime environments toward the very processes developers use to build and ship software. No organization should assume “we don’t use npm, so we’re safe”, because even downstream dependencies or dev toolchains can become the launch pad.”

This illustrates the need for a software bill of materials so that it is clear where software components come from. But beyond that, developers need to know and have full confidence in the components that they use. That way the chances of this sort of attack are lessened.

Leave a Reply

Discover more from The IT Nerd

Subscribe now to keep reading and get access to the full archive.

Continue reading