The Shai-Hulud npm supply chain attack explained
In this article
Summary
According to cybersecuritynews, the Shai- Hulud 2.0 npm supply chain attack has compromised nearly 1,200 organizations, including major banks, government bodies, and Fortune 500 technology firms.
This article highlights what Shai-Hulud is exactly, where it got its name from (and why it makes a lot of sense) and why managing open source risks is paramount.
Our IT portfolio governance platform, Sigrid®, can help your organization stay ahead in situations like these.
We have a specific ‘Open Source Health’ feature that gives you a clear view of open-source vulnerabilities, license compliance, and legal risks across your software landscape—so you can see where to act first.
In addition, with Sigrid CI for Open Source Health, your development teams will receive an alert in their pipeline as soon as an open-source vulnerability is present.
What is the Shai-Hulud npm worm?
If you’ve read Dune (Or watched it), the name Shai-Hulud might ring a bell. However, we’re not talking about the giant sandworms from the books or the recent films; that’s just where this malware worm got its name.
The first Shai-Hulud incident surfaced in early September and, at the time, was the largest npm attack on record, with attackers stealing $50 million in cryptocurrency.
But between November 22 and 23, the new wave began and was aptly dubbed: “the second coming”.
On November 24, 2025, Shai-Hulud 2.0 was identified. It’s a fast-spreading piece of malicious code that recently slipped into popular open-source building blocks many JavaScript teams reuse. Pull one of those blocks, and the malware can try to steal access keys, post them publicly on GitHub, and—in the worst case—attempt to wipe files.
It also copies itself, which helps it spread quickly, which is why the Dune reference is so fitting.
Not just because the sandworms are terrifying and virtually indestructible, but because the name Shai-Hulud is derived from the Arabic (شيء خلود (šayʾ khulūd) and roughly translates to “thing of immortality”—a nod to something that tries to live on by replicating itself.
Shai Hulud 2.0 slipped into widely used open-source components and tried to copy itself, steal access keys, and in some cases even attempt file wipes. Latest reporting indicates it has compromised nearly 1,200 organizations, including major banks, government bodies, and Fortune 500 technology firms.
What is open source?
Open source is a model for software development where the source code is made publicly available, allowing anyone to view, modify, and distribute it. So, in practice developers reuse libraries, because it makes no sense to rebuild common parts from scratch.
Open source is widely used in software development.
According to the 2025 State of Open-Source Report, 58% of organizations increased their use of OSS over the past year. While OSS, no doubt, enables faster development, lower costs, and greater flexibility, it also introduces hidden risks if not properly managed.
But as we discussed in our State of Software report, adoption comes with trade-offs. Libraries can:
- Contain vulnerabilities, leading to potential exploitation;
- Carry restrictive licenses, creating legal risk;
- Lose community support, putting long-term maintenance at risk.
That’s why managing third-party open-source dependencies matters and why continuous monitoring keeps risk under control.
And as Jan Laan, Senior Security Consultant at Software Improvement Group explained in a previous AMA session: “You don’t want to get hacked.”
For example, malicious code can be introduced into projects, and unpatched vulnerabilities in the software or its dependencies can be exploited by attackers to gain access to systems, steal data, or cause disruption.
This is exactly what happened with the Shai-Hulud breach.
How to protect your organization from the Shai-Hulud npm worm
Incidents like Shai-Hulud 2.0 start upstream and can ripple into your systems because many share the same components. Even if bad packages are taken down, it may have already spread across your systems.
Leaders need two things at once:
- Early warnings where day-to-day software changes happen (so teams catch issues before they spread), and
- A portfolio-level view to know everything is under control (so you can prioritize fixes and act where necessary).
How Sigrid® helps
In it’s essence, Sigrid’s Open-Source Health feature can be seen as a software composition analysis (SCA) that addresses vulnerabilities, licence compliance, and legal issues within your libraries head on.
However, much more than just regular SCA tools, Sigrid’s Open-Source Health feature includes a benchmark-based star rating system. This unbiased and fact-based scoring method offers a consistent standard aligned with current market data and industry best practices, changing how you perceive and act upon open-source risks.
- One clear view: Sigrid evaluates your open-source libraries across six key areas: known vulnerabilities, freshness, activity, stability, management, and legal licenses. This ensures a thorough examination of the software’s reliance on open source components and their risks.
- Early warnings in delivery: With Sigrid CI for Open Source Health, developers get alerts in the pipeline when risky components appear so problems are caught sooner.
- Better priorities: You see risk and impact across the portfolio, then focus effort where it matters most.
While standalone Software Composition Analysis (SCA) tools focus solely on dependencies, Sigrid’s Open Source Health is part of a broader software quality platform. This integration allows you to see how open source usage relates to other aspects of your software, providing a more comprehensive view.
Learn more about Sigrid’s here.