The worm you catch by opening a file

If somebody writes or maintains software for your business, the standard advice about supply-chain risk has always had a reassuring shape: be careful what you install. Do not pull in packages you have not vetted. Check what your dependencies are before you add them. It is good advice, and this month a piece of malware quietly stepped around it.

The uncomfortable update is that a developer no longer has to install anything to be caught. Opening a project in their code editor can be enough.

What happened

Earlier this month we wrote about an npm worm that poisoned hundreds of packages while carrying a valid signature. npm is the storage cupboard that nearly all JavaScript and Node.js software pulls its building blocks from, and a single business application typically draws in hundreds of these without anyone choosing them individually. That worm belongs to a family researchers named Shai-Hulud, after the sandworms in Dune, because it spreads on its own.

A new wave of it, reported by The Register on 15 August and dubbed ChainDrop by Microsoft and others, has added techniques that make it far harder to spot. It infected 444 packages, including deep, unglamorous building blocks like keyv, flat-cache, and cache-manager that are collectively downloaded around two billion times a month. Those are not packages most developers think about. They are the plumbing underneath the packages they do think about.

Two changes matter.

First, it hides. When the worm runs, it searches the machine for credentials: npm publishing tokens, cloud keys, secrets in shell settings, in environment variables, even in the computer's live memory. It sends what it finds to the attacker, then rebuilds the affected packages to carry its own code inside the downloadable archive, the tarball, rather than in the visible source. So a developer who reads through the project's source code on GitHub sees nothing wrong, because the tampering is not there. It is in the packaged download.

Second, and this is the part that breaks the old advice, it no longer waits for an install. If it finds credentials for GitHub, it uses them to write a small configuration file directly into the developer's code repositories, across every branch it can reach. The next developer who opens one of those repositories in a common editor like VS Code, or in an AI coding assistant, triggers a background task that starts the whole cycle again on their machine. No package was installed. A project was simply opened.

Why this reaches further than it looks

It is tempting to file this under "a developer problem" and stop reading. Two things make that a mistake for a business owner.

The first is that the credentials it hunts for are the keys to everything else. Cloud keys, database logins, publishing tokens: the same class of secret that, in the wrong hands, empties a database or ships poisoned software under your name. We wrote separately about how one leaked key emptied a charity's entire customer database. This worm exists to harvest exactly those keys, at scale, from developers' machines.

The second is automation. npm packages are woven into the automated systems that build and release software, the pipelines that assemble an application every time code changes. Those systems routinely pull the latest small updates to dependencies on their own. That gives the worm a quiet route into fresh builds without a human ever clicking anything, which is precisely the sort of unattended machinery a small firm rarely has eyes on.

The deeper point is one we keep arriving at from different directions. The advice to avoid risky downloads assumes the danger arrives as a thing you chose to fetch. More and more, it does not. It arrives inside something you already trusted, or through an action as ordinary as opening a file, the same shape as the browser extension that emptied thousands of private code repositories.

What to do

You do not need to become a security engineer to ask the right questions. If anyone builds or maintains software for you, in-house or outside, these are reasonable and specific.

• Ask whether they have checked their machines and repositories for this. The concrete signs, per the researchers, are configuration files nobody added: a .claude/settings.json or a .vscode/tasks.json that no one remembers creating. Crucially, they should check every branch of a repository, not just the main one, because that is where this hides. The security firm SafeDep has published the list of affected packages and versions to check against.
• Treat any infected machine as leaked credentials, not just cleaned-up malware. If the worm ran, assume the keys and tokens on that machine are in someone else's hands. They need changing, from a machine known to be clean. Deleting the malware does not undo what it already sent.
• Ask how new dependency updates get in. If your build system automatically pulls the newest versions of its building blocks with no one reviewing them, that is the door this walks through. Pinning to known, checked versions and updating deliberately is the boring fix, and it is the right one.
• Keep developer credentials short-lived and narrow. A publishing token that can push to one package, and expires, is a far smaller loss than one that never expires and can push to fifty. This is the same lesson as any other key: give it the least it needs.

The takeaway is not that open-source building blocks are unsafe to use. Nearly all software is built from them, and that is fine. It is that "we only install trusted packages" is no longer the whole defence, because the newest attacks do not wait to be installed.

How Steelwise can help

Working out how software gets built and shipped in your business, where the keys live, and how an attack like this would actually reach you, is the kind of security review we do for smaller firms without a dedicated security team. Get in touch.

Further reading

• NCSC guidance on supply chain security
• NCSC guidance on secure development and deployment
• NCSC guidance on vulnerability management

← All filings