In the epic sci-fi adventure series Dune, the mighty Shai-Hulud sandworms inspire fear and awe among the Fremen natives of their home planet Arrakis. Just a few weeks ago, their digital namesake appeared in the open source ecosystem, burrowing its way through npm software packages. That worm has now compromised hundreds of these reusable modules of JavaScript code, published on the world’s largest software registry (npm). They are routinely downloaded by countless enterprises millions of times each week.
This wasn’t even the first major open source threat campaign to surface in the space of a month. Security experts initially rang alarm bells at the end of August, in what was dubbed the ‘S1ngularity’ attack. In that campaign, threat actors targeted the popular ‘Nx’ package, exploiting a flawed GitHub Actions workflow in a related Nx repository. This allowed them to publish a malicious version of the package on npm, the world’s largest collection of open source software. The end goal? To steal GitHub tokens, npm tokens, SSH keys, .env files, and crypto wallets. Thousands of secrets from developer machines were compromised in this way.
It got even worse a few days later. In a separate campaign, npm maintainers, including ‘Qix’, were targeted with phishing emails that hijacked their accounts and injected malware into at least 18 popular packages typically downloaded billions of times each week. The malicious versions, which contained crypto-stealing malware, were removed within hours – but not before many users had already downloaded them. One vendor estimated that the malicious code reached as many as 10% of cloud environments.
Then came the world’s first wormable malware to spread via npm. “Once it lands on a developer machine or continuous integration (CI) system, it steals tokens and secrets, then republishes every package those tokens can touch,” says the chief technology officer for Sonatype, Brian Fox. “That makes the blast radius huge: one compromised account quickly turns into hundreds of poisoned packages.”
For end-user organisations, it means an increasingly hazardous open source supply chain. The secrets Shai-Hulud steals could give threat actors access to enterprise cloud and developer environments, exposing some of the most valuable corporate IP to theft and sabotage. The potential financial and reputational damage this could cause is immense.
“Once Shai-Hulud runs, it steals credentials that can later be used to compromise other parts of your supply chain. That means your supply chain could be poisoned even if nobody on your team ever touched the original malware,” Fox continues. “The purpose of harvesting secrets is persistence and scale. With GitHub, npm, and cloud tokens in hand, attackers can mass-publish backdoored versions … and embed themselves deep in the software supply chain.”
Taming the beast
Shai-Hulud is noteworthy for several reasons. According to Trend Micro, it began life as part of the S1ingularity attacks on Nx and others. After compromising a maintainer account via an old-fashioned phishing attack, the threat actors injected the worm into a package and let nature take its course. The 3MB+ of malicious JavaScript looks for other packages in the same developer environment and injects itself into them. When these are eventually published by the unwitting developer and then downloaded by a user, they execute a malicious bundle.js file.
The malicious script is designed to steal npm, GitHub, AWS and GCP tokens, and also installs TruffleHog. This open source tool can detect as many as 800 different types of secrets, including API keys, access tokens, database passwords and encryption keys. This stolen data, in turn, is exfiltrated to public GitHub repositories named ‘Shai-Hulud’. In some hijacked GitHub accounts, a new branch (also confusingly named after Dune’s most popular sandworm) is added to existing repositories with a malicious workflow to exfiltrate accessible tokens.
The worm also tries to migrate private GitHub repositories belonging to victims to newly minted public copies, in a likely attempt to access secrets and source code hardcoded in these repos. According to experts, the stolen code could be searched for vulnerabilities to exploit in future attacks.
JFrog VP security research Shachar Menashe estimates that Shai-Hulud may have infected as many as 500 npm packages this way, some of which have millions of weekly downloads. And although the current wave of attacks is over, it may have a long-lasting impact on compromised organisations.
“This is a much stronger infection method than uploading a new malicious package, since everyone that already uses the previous, legitimate, package will get infected when updating to the compromised version,” he says “This infection method led to hundreds of thousands of installations of the Shai Hulud worm.
“We do not know exactly how many credentials were stolen as part of this attack, and these credentials can be used to fuel more attacks, either with the same payload or different payloads.”
If they encounter a similar campaign in the future, Menashe recommends developer teams delay upgrading to new package versions. “Specifically, we have seen that employing a 14-day delay before upgrading to the latest version of a package should be enough to protect against the vast majority of package hijack attacks, since in this time period the attack is discovered and the malicious versions are removed,” he says. “Organisations with more risk appetite can choose to employ a shorter delay, but 2-3 days would be the absolute minimum we would recommend.”
Given the ubiquity of open source code in modern development environments, organisations must find a way of managing threats like Shai-Hulud without impacting productivity, argues Redwood Software CISO, Andy Sharma. He cites three key pillars: centralised control, continuous visibility, and proactive defence.
“We can no longer rely on developers to manually vet every package,” says Sharma. Instead, he explains, companies must leverage a single, authoritative source like an artefact repository for all software components to provide a secure ‘staging ground’ for vetting and managing all of its dependencies. “This allows companies to scan for vulnerabilities and malicious code before they ever enter the development environment, automatically blocking risky components and ensuring that only known-good software is used.”
This approach can prevent the risk of auto-update snafus, adds Sharma, where security patches unwittingly inject dangerous vulnerabilities into software. It could also help CISOs better communicate the value of their efforts to the board, via clear, quantifiable metrics.
“CISOs can report on the percentage of approved versus unvetted components, the time to remediate critical vulnerabilities, and the overall security posture of the applications,” Sharma continues. “This moves the conversation from low-level technical jargon to strategic business risk, allowing CISOs to demonstrate a clear return on investment.”
Fixing open source cybersecurity
The bigger problems may be harder to fix. As evidenced by recent campaigns, threat actors are increasingly singling out maintainers as a single point of failure in the open source ecosystem. These are the individuals who keep projects alive, frequently on a voluntary basis. They’re often overwhelmed with the workload and may not even have any dedicated cybersecurity support. That makes them an attractive target for phishing – especially if they maintain popular packages, as in the case of the Qix compromise.
“Future open-source threats will not just be about injecting malware; they will be about exploiting human behaviour and using emerging technologies to scale attacks,” says Sharma. “Attackers will continue to move upstream, targeting individual maintainers of critical, widely used open source projects through highly sophisticated social engineering campaigns. A single compromised developer account can be leveraged to infect millions of downstream users, making it a high-return, low-effort attack for adversaries.”
Weaponisation of large language models (LLMs) to automate and accelerate attacks will also make the job of maintainers more challenging, he argues. “Attackers can use LLMs to rapidly find vulnerabilities in codebases, generate more convincing phishing emails, and even produce malicious, yet seemingly benign, code that is difficult for humans to detect,” Sharma says. “This new form of AI-driven threat will erode trust in open source and make it harder to distinguish between legitimate code and a cleverly disguised attack.”
The problem may be broader still. Both maintainers and the infrastructure on which open source depends are critically underfunded, argues an open letter penned recently by the Open Source Security Foundation, the Rust Foundation, and other self-styled ‘stewards of public open source infrastructure.’ They argue that the economic and operating model on which open source is based is crumbling. Huge inefficiencies, such as duplicate downloads, are straining the infrastructure to the breaking point. Meanwhile, large commercial users are extracting huge economic value without contributing enough to sustainability, they claim.
These organisations, some of the largest on the planet, are unfairly consuming the lion’s share of open source resources, the stewards argue. Their case is a compelling one. A recent Harvard study estimates that open source generates $8.8 trillion in economic value. Yet some maintainers still struggle on their own, or with a tiny team, to support hugely popular packages.
“The common thread through all these incidents is the financial unsustainability of open source infrastructure. Billions of dollars of enterprise value ride on systems maintained by a handful of volunteers, with no alignment between those who depend most on them and those who keep them running,” concludes Sonatype’s Fox.
“We need real investment from major consumers to support both maintainers and the infrastructure itself. Without that, Shai-Hulud won’t be the last worm we see.”
Read more: How much digital sovereignty does the UK have left?
