Shai-Hulud: 868 software packages poisoned in one day

🇫🇷 Lire en français : Shai-Hulud : 868 briques logicielles piégées le 4 août 2026

On 4 August 2026, a piece of self-replicating malware poisoned 868 software packages used by millions of websites and applications worldwide, together accounting for more than 2 billion installs a month. Within an hour it had gone from 10 packages to more than 440. If you own a website or an application built in the past few years, you probably noticed nothing at all. That is exactly what makes this episode worth a business owner’s attention: the problem is invisible from your screen, and it gets sorted out with the person who manages your site.

We have already explained why a project built without code review carries its flaws from the very first package installed. This article does not repeat that case: it covers what happened on 4 August, what it actually changes, and what to ask for now.

Shai-Hulud: what happened on npm on 4 August 2026  

  Tip

An attacker took over the account of a widely followed developer, then published poisoned versions of his software packages carrying a perfectly valid technical signature.

To set the scene without the jargon: when an agency builds a modern website or application, it does not write everything by hand. It assembles ready-made software packages, written by other developers and made freely available in a large parts warehouse called npm. A reasonably ambitious site easily ships with several hundred of them. That is normal, it is efficient, and it is what makes it possible to deliver a project in weeks rather than years.

On 4 August 2026, an attacker took over the GitHub account of Jared Wray, the developer who maintains a family of heavily used packages that handle website caching: keyv, cacheable, flat-cache, file-entry-cache. On its own, keyv is downloaded roughly 127 million times a week. The attacker did not need to break anything: he pushed his code straight into the official project, then cut new releases immediately afterwards. Those poisoned versions therefore carried a legitimate technical signature, which made them indistinguishable from a normal update.

From there the program behaved like a worm: once installed on a developer’s machine, it stole their access keys, used them to modify the other packages that developer maintained, and published fresh poisoned versions in turn. From 10 packages at the outset it reached more than 440 packages in under an hour, according to analyses published the same day by JFrog and ArmorCode. The consolidated tally from researchers came to 868 packages across 1,381 versions. Singapore’s Cyber Security Agency, in its official advisory of 6 August 2026, records more than 1,300 compromised versions representing 2 billion monthly downloads.

The worm’s name, Shai-Hulud, is borrowed from the sandworms of Dune. The attackers run the reference all the way: the repositories they create to dump the stolen credentials carry names lifted from the novel, fremen or sardaukar, tagged “Shai-Hulud: Here We Go Again”. That is about the only entertaining part of the affair.

What this supply chain attack changes for your business  

  Tip

This attack was not after your customers or your passwords: it was after the technical keys held by the people who build and deploy your site.

It is worth being precise about the real risk, because the trade press gives you plenty to worry about. What this program steals is not your visitors’ passwords or your shop’s orders. It is the technical keyring: access tokens for hosting, for the code repository, for cloud services (Amazon, Google, Microsoft), for automated deployment tools. In other words, the credentials that let someone change your site, not the data stored on it.

The danger lies in what comes next. With those keys, an attacker can come back later, alter your site, slip in a fraudulent payment page, or reach the databases those keys unlock. It is a deferred risk rather than an immediate disaster. That is also why it so often goes unnoticed: nothing breaks, nothing shows, the site keeps running normally.

The second point that matters to a business owner: you are only affected if something was installed or redeployed after 4 August 2026. A site that has been live for two years and untouched since could not have picked up the poisoned versions, because it still runs on the packages installed the day it went live. The risk sits with active projects: those under development, those receiving regular updates, and developers’ own machines.

  Warning

The natural reflex, “I’ll just update everything right now to be safe”, is the wrong move here. The update itself was carrying the trap. Before redeploying anything, check which versions are installed.

That reversal is what makes this wave disorienting, professionals included. With a classic flaw, such as the one we documented in the core of WordPress in July, updating is the fix. Here it was the delivery vehicle.

What to do: four questions to put to your web provider  

You do not have to run these checks yourself, and you should not have to. You are, however, entitled to ask for them. Here are the four useful questions, in order, with what a good answer looks like.

1. “Does our site use npm packages?” If the answer is no (static brochure site, WordPress with no custom development), the matter largely stops there on the server side. If the answer is yes, move on. A hesitant answer is itself information.

2. “Has anything been installed or deployed since 4 August 2026?” This is the question that bounds the risk. A serious provider answers by checking the deployment history, not from memory.

3. “Can you compare our dependencies against the list of compromised versions?” The lists of poisoned versions are public and published by security agencies. That comparison can be automated and takes minutes on a small business site.

4. “If we were exposed, which credentials need rotating?” Singapore’s agency recommends treating the machine as compromised, rotating every exposed credential (cloud access, repository tokens, SSH keys) and rebuilding the environment rather than simply uninstalling the package. Removing the poisoned package is not enough once the keys are already gone.

  Note

What we see in the field. On the projects we take over, the difficulty is almost never technical: it is organisational. The site was delivered, the provider moved on to something else, and nobody is watching the ecosystem’s security alerts any more. When a wave like the one on 4 August arrives, the question “who is watching?” simply has no answer. That gap, rather than the flaw itself, is what costs money.

If nobody holds those answers today, that is the useful signal in this story. It is not a reproach aimed at a provider who did good work on the build: keeping watch over a dependency estate over time is a different job from building a website, and that is exactly what managed hosting covers.

Three waves in eleven months: the Shai-Hulud trajectory  

The instructive part is not the 4 August wave taken on its own, it is the trajectory. Three episodes in under a year, all documented by official agencies.

September 2025. A phishing campaign catches a developer’s account and more than 500 packages are compromised. CISA, the US cybersecurity agency, issues an alert on 23 September and recommends pinning dependency versions to releases published before 16 September. This was Shai-Hulud’s first appearance, the one we referred to in our article on AI-assisted development.

November 2025. A second wave, named “The Second Coming” by its own authors. Between 21 and 23 November, hundreds of packages and more than 25,000 repositories are hit within hours. The malicious code now runs before installation, so it fires even when the install fails. And when stealing the keys does not work, the program tries to destroy the victim’s home directory. Sabotage as plan B.

August 2026. The third wave, this one. No major technical break from November, but a more awkward demonstration: the mechanism still works, eleven months and two international alerts later.

What this curve describes is the fragility of the trust model modern software rests on. It holds on one simple assumption: a package signed by its legitimate author is safe. That is true as long as authors’ accounts are not taken over, and false the moment an attacker can pass for them. Which is exactly what has now happened three times.

None of this is a reason to walk away from modern technology. These software packages remain what makes it possible to deliver solid projects at a price a small business can afford. But they require someone to be watching. A website is not an object you deliver once: it is a living installation that needs someone tracking the alerts. That is the lasting lesson of 4 August.