Open Source Worm Code Sparks New Wave of npm Supply Chain Attacks
- 41 minutes ago
- 3 min read
A new phase in software supply chain attacks is unfolding across the JavaScript ecosystem, as publicly released worm code fuels a surge of low-effort but highly effective malicious packages on npm. Security researchers warn that what began as a proof of concept has quickly evolved into a scalable attack model that favors speed over sophistication.
The shift follows the public release of the Shai-Hulud worm source code, which has enabled copycat attackers to rapidly deploy variations with minimal technical skill. Within days, multiple malicious packages appeared on npm, some designed to impersonate popular libraries through minor naming variations.
Unlike traditional supply chain compromises that rely on hijacking trusted maintainers, this new wave exploits the open nature of package ecosystems. Attackers are creating entirely new packages under fresh identities, bypassing many of the protections designed to secure established projects.
“We argued back in December that Shai-Hulud wasn’t an incident; it was a prototype for a new class of attack that weaponizes developer identity and the implicit trust baked into CI/CD pipelines. Glassworm validated those predictions in March, and the copycats surfacing on npm this week are the next step in the same arc.”
Security teams are now observing attackers running multiple types of malware simultaneously from a single account. These include information stealers targeting cloud credentials, botnet payloads for distributed denial-of-service attacks, and near-identical clones of the original worm, all deployed in rapid succession.
Münch adds that this pattern reflects a broader transformation driven by automation.
“A single threat actor is already running multiple payloads in parallel, a Shai-Hulud clone, plain infostealers, a DDoS botnet, all from one npm account, all generated and shipped fast enough that they look machine-assembled. That’s exactly the AI-assisted scaling we unfortunately expected: attackers no longer need to be sophisticated; they just need to be quick.”
The implications are significant for modern development workflows. Continuous integration and continuous deployment pipelines often rely on automated dependency installation, which can execute code during setup. In many environments, these processes implicitly trust any package referenced in a project’s dependency tree.
That trust model is now being actively exploited.
“The hard part is admitting that implicit trust in every dependency, every maintainer, every IDE extension, and every developer workstation is no longer a defensible posture,” Münch says. “When you open source a worm, you get an arms race, and that race just started its first lap on npm.”
Existing security controls, particularly those focused on publisher identity and account protection, offer limited defense against this tactic. Features like multi-factor authentication and trusted publishing are designed to prevent account takeovers, not to stop attackers from creating malicious packages from scratch.
Instead, experts are urging organizations to shift focus to the consumer side of the supply chain. This includes restricting install-time script execution, enforcing delays before adopting newly published packages, and monitoring for unusual dependency behavior across development environments.
Modern package managers have already introduced safeguards that can reduce risk. These include blocking lifecycle scripts by default, implementing release age thresholds to avoid newly published packages, and detecting suspicious changes in publishing credentials.
Still, adoption remains inconsistent, especially among teams that continue using legacy tooling without stricter controls enabled.
The broader concern is not the scale of current infections but the trajectory of the threat. Early malicious packages linked to this campaign have relatively low download counts, but researchers emphasize that speed and replication, not volume, define this new attack model.
As the barrier to entry drops, the number of capable attackers increases.
For security leaders, the message is clear. Software supply chain security can no longer rely on trust by default. In an ecosystem where attack techniques are openly shared and rapidly reused, defense strategies must assume that any dependency could be hostile until proven otherwise.