Your website has hundreds of authors you have never met

On the morning of August 4, 2026, someone published a poisoned version of a small, boring piece of software called keyv. Almost nobody installs keyv on purpose. It is a caching helper that sits four or five layers down inside other things you actually chose. By the end of the day the same attack had spread to more than 400 packages, and within 48 hours security researchers counted over 1,300 poisoned versions on the npm registry with a combined two billion downloads a month.

If you own a small business with a website or an app, none of those names mean anything to you, and that is exactly the point worth understanding.

The part nobody explains to the person paying the invoice

When a developer builds you a website or an application, they do not write all of it. Nobody does, and nobody has for fifteen years. They write the part that is specific to your business, and for everything else, date formatting, image resizing, payment handling, sending email, they pull in existing pieces from a public library. In the JavaScript world that library is called npm, and it is enormous.

The consequence is that a fairly ordinary web application has somewhere between several hundred and a few thousand of these pieces underneath it. Your developer chose maybe twenty of them directly. The rest arrived because the twenty depend on other things, which depend on other things. Each one was written by a stranger, and each one has a maintainer with a password and a publishing key.

This is not a scandal. It is how modern software gets built, and the economics are overwhelming: nobody is going to hand-write a date library for a dentist’s booking page. But it does mean your project inherits the security of a few hundred accounts belonging to people you will never meet.

Attackers worked that out, and 2026 has been the year they industrialized it. Sonatype, which tracks this, identified more than 454,600 new malicious open source packages during 2025 alone, pushing the cumulative total past 1.233 million, a 75 percent jump year over year. By the second quarter of 2026 their count had reached 1.8 million.

What happened on August 4

The August incident is worth walking through, because the mechanics explain why the usual advice does not apply.

The worm is a variant of a malware family researchers call Shai-Hulud, and Microsoft tracks this version as ChainDrop. It works like this. A compromised package includes a preinstall script, a small program the package manager runs automatically the moment the package is downloaded, before anything is even used. That script pulls down a second stage, which then goes hunting through the machine it landed on for anything worth stealing: cloud provider credentials, GitHub tokens, deployment secrets, CI/CD pipeline keys, API keys for AI tools, crypto wallets.

Then comes the part that makes it a worm rather than a theft. Among the credentials it collects are the publishing keys of the developer whose machine it just infected. It uses those keys to publish backdoored versions of that developer’s own packages. Those get installed by other developers, whose keys it steals, and so on. That is how one compromised maintainer account became 400 packages in a morning.

It was also unusually well built. Instead of hard-coding the address of the server it reports back to, which is the thing defenders block first, it looked the address up from an entry on the Ethereum blockchain. You cannot take that down with a phone call to a hosting provider.

This was not a one-off

Five months earlier, on March 31, the same category of attack hit axios, one of the most widely used packages in the entire ecosystem, roughly 100 million downloads a week and more than 174,000 other packages depending on it.

An attacker took over the npm account of the project’s lead maintainer and published two new versions, 1.14.1 and 0.30.4. The actual code of the library was untouched. All they added was one new dependency, plain-crypto-js, which the library never uses anywhere. Its only job was to run a postinstall script that dropped a remote access trojan onto the machine, working across macOS, Windows, and Linux.

The malicious versions were live for roughly three hours, from 00:21 UTC until npm pulled them at about 03:25. Three hours is not long. It is also more than enough, because somewhere in the world it is always the middle of a workday, and automated build systems install fresh copies of dependencies thousands of times an hour without a human watching.

Microsoft Threat Intelligence attributed that one to a North Korean state actor it tracks as Sapphire Sleet, and Elastic’s researchers independently tied the payload to a DPRK-linked cluster. Microsoft attributed a further npm compromise in June, of a package called Mastra, to the same group. This is not teenagers defacing websites. It is a nation-state treating developer laptops as a way into everything those laptops can reach.

Why your antivirus was never going to catch this

Three reasons, and they are worth being blunt about.

It runs on the builder’s machine, not on your server. The malware executes during installation, on a developer’s laptop or inside an automated build pipeline. By the time your website is deployed, the malicious code may not be in it at all. What left the building was the credentials.

The package was legitimate yesterday. There is no suspicious download, no unknown vendor, no dodgy attachment. It is the same package name, from the same author, that your project has used safely for three years. Only the version number changed.

The damage is not to the website. It is to everything the compromised credentials unlock: the cloud account, the deployment pipeline, the source code repository, the database. A site can look perfectly healthy while the keys to it are already gone.

This is the same shape as the breach of the remote monitoring tool that IT providers use that we wrote about last week. The compromise does not start with you. It flows downhill from whoever has access.

The defenses that actually work

The good news is that the industry response over the past year has produced a small number of controls that are genuinely effective, cheap, and mostly a matter of flipping a setting.

A cooldown before installing brand new versions. This is the single highest-value change, and it is close to free. Poisoned releases get spotted and pulled within hours, as the three-hour axios window shows. So do not install anything that was published in the last few days. npm added a min-release-age setting in version 11.10.0 of its command line tool, measured in days; pnpm has minimumReleaseAge, measured in minutes, and pnpm version 11 turns it on by default at 1440 minutes, which is 24 hours. A one-week cooldown would have blocked every incident described in this article, at the cost of getting new features seven days later than you otherwise would.

Do not let packages run scripts on install. Both the axios attack and the August worm depended entirely on preinstall and postinstall hooks, code that a package gets to run automatically just for being downloaded. Almost no package legitimately needs this; the handful that do are compiling something. pnpm version 10 and later blocks these by default and makes you name the exceptions explicitly. That one default would have neutralized both attacks.

Commit the lockfile, and treat changes to it as code. A lockfile records the exact version of every one of those several hundred pieces. With one committed, a build installs precisely what was reviewed, not whatever happens to be newest that morning. A dependency version changing should show up in a code review like any other change, because that is what it is.

Automated vulnerability scanning in the pipeline, not on a calendar reminder. Advisories get published against dependencies you have not touched in a year. Something needs to check continuously, and it needs the authority to fail the build rather than file a note that somebody reads eventually.

Short-lived publishing credentials. This one is for anyone who publishes packages rather than just consuming them. npm permanently revoked its old-style long-lived access tokens on December 9, 2025, capped the remaining write-capable tokens at a 90-day lifetime, and pushed publishers toward trusted publishing, where the build system gets a temporary credential scoped to one job instead of a permanent key sitting in a settings file. Stolen credentials are the fuel these worms run on. Credentials that expire in minutes do not burn well.

What we do here

We are not going to pretend this is solved, because it is not. But concretely, on this website and on client projects:

Every dependency version is pinned in a committed lockfile, so a build installs the reviewed set and nothing else. Every pull request and every push to the main branch runs a vulnerability scan against that lockfile, and the scan fails the build on any unresolved finding, with no severity threshold to argue about. The scanner binary itself is pinned by version and verified against a published SHA256 hash before it runs, because a supply-chain gate that takes its own tooling on trust is not much of a gate. The rare cases where we accept a finding carry a written justification and a hard expiry date, so the scanner resurfaces it automatically and a suppression cannot quietly become permanent.

We are also adding install cooldowns across our projects on the back of this month’s incident, which is the honest version of this section: the August worm changed our own checklist too.

If you are the one paying for the software

You do not need to audit anything yourself. You need four answers from whoever builds and maintains your systems. Any competent developer will answer these in a sentence each, and a blank stare is itself information.

1. Is there a lockfile committed, and does a build install exactly what is in it?
2. Is there a cooldown on newly published dependency versions, and how long is it?
3. Do dependencies run install scripts automatically, or is that blocked with a named list of exceptions?
4. If a developer laptop were compromised tomorrow, which of our credentials would be on it, and how quickly could they be rotated?

That last one is the one people skip, and it is the one that determines how bad a bad day gets. The answer should not be “all of them, indefinitely.”

The bottom line

Software supply chain attacks are not an exotic risk anymore. They are the mainstream way into technical organizations in 2026, they are run by well-resourced state actors, and the targets are increasingly the tools and the people who build software rather than the software itself. Everything you run sits on top of code written by strangers, and that is fine, provided somebody has thought about what happens when one of those strangers has a bad week.

The defenses are unglamorous and mostly consist of configuration files. That is the good news.

If you want a straight answer about how your own project handles this, or you are not sure who to ask, send us a note. We are happy to look.