The 2025 npm worm that shook the software supply chain

As a worm spread through hundreds of npm packages in 2025, it didn't exploit a vulnerability – it exploited the architecture. The systems that developers relied on had quietly become attack infrastructure.

When the Shai-Hulud npm worm began spreading through hundreds of JavaScript packages in 2025, it didn’t feel like just another supply-chain incident. It felt like a moment of reckoning, one that forced developers and security teams to confront an uncomfortable truth: that the systems they rely on to build and ship software at scale had quietly become attack infrastructure.

Hundreds of npm packages were trojanized. CI pipelines were turned into propagation engines. And perhaps most unsettling of all, the attack didn’t depend on a zero-day vulnerability or an exotic exploit. It succeeded by abusing the very workflows that underpin modern software development.

Exploiting trust

At a technical level, Shai-Hulud is believed to have begun with a compromise upstream of npm itself. Michael Clark, Senior Director of Threat Research at Sysdig, says the most likely entry point was leaked credentials or a misconfigured GitHub Actions workflow.

“GitHub Actions are very attractive targets because they often require credentials for other parts of the software build chain, including the npm package repository, which allows them to automatically deploy new versions,” Clark explains.

“Once the attacker has that key, they have access to the corresponding npm repository where they can plant the worm.”

From there, the compromised package didn’t just deliver malicious code – it also actively searched for more trust to abuse. Each infected install looked for npm tokens, GitHub secrets, and cloud credentials, then used them to move laterally and push new trojanized versions.

Then, it got worse. In November, SHA1-Hulud emerged as a more aggressive variant that went beyond simple credential theft. It attempted to convert victim machines into attacker-controlled GitHub Actions runners and launched destructive attacks against developers' systems.

Modern build systems are complex and deeply interconnected, says Clark, explaining that once an attacker gets one foot in the door, there’s often a lot of sensitive information within reach.

“These are the main vulnerabilities that Shai-Hulud exploited,” he said.

The flaw hiding in plain sight

The scale of the compromise was shocking, but the real story runs deeper. These attacks succeeded because they exploited a fundamental design problem that's been hiding in plain sight for years.

"CI/CD pipelines now function as high-privileged machine identities, yet there are no security controls to assume they will be under attack," says Nik Kale, Principal Engineer at Cisco, specializing in software supply-chain trust.

The problem, as it usually is, is that we've optimized for speed and convenience at the expense of security. Kale explains that CI/CD systems inherit ambient authority, such as broad access to secrets, repositories, and publishing credentials, because, like everyone, developers too need things to "just work."

But this creates what Kale calls a "model of vulnerability," especially when automated identities and the transitive trust relationships between suppliers in the software delivery pipeline become attack targets.

"Even though CI/CD is not inherently the weakest link in a software delivery system, it has become one of the most appealing targets for attackers, primarily due to its centrality and the default privileged posture associated with it," Kale explains.

In essence, the worm didn't need to break through sophisticated defenses. It just needed to compromise one set of credentials in a system that was designed to trust by default.

The structural fix

When asked what single change would prevent another Shai-Hulud, Kale is clear: "Establish least-privileged, ephemeral identities as the default for CI/CD and package publishing, rather than an advanced configuration."

He suggests eliminating long-lived credentials from pipelines and scoping permissions to exactly what each workflow needs, nothing more.

Moreover, publishing rights should be attached to verifiable provenance instead of ambient tokens. In essence, he says, automation should authenticate to the narrowest extent possible, and for the shortest duration possible, just as zero-trust service workloads do.

"If ecosystems adopted the same level of rigor for machine identities as for production services, attacks similar to Shai-Hulud would be much more brutal to scale, regardless of whether a package or a developer is compromised," Kale explains.

Clark acknowledges that without knowing the exact root cause, it's impossible to say with certainty what would have stopped the initial breach. But the spread could have been contained. He says GitHub security should be monitored closely, especially GitHub Actions and Personal Access Tokens (PATs). Using fine-grained tokens instead of broad PATs should be standard practice.

The conversation on this topic is live. Join in the discussion.

He acknowledges that npm recently made changes to eliminate long-lived tokens, which helps limit the damage when credentials are stolen, and adds that runtime threat detection in build environments can also help catch suspicious behavior, such as attempts to exfiltrate data or modify the build process.

All said and done, both experts agree that Shai-Hulud succeeded because modern software delivery quietly accumulated enormous trust in automated systems, and attackers noticed.

If anything, they believe, Shai-Hulud may not just be remembered as the npm worm that shook the software supply chain, but also as the one that exposed its fragility.

Unlock more exclusive Cybernews content on YouTube.