Back-to-back npm supply chain attacks: our products are checked and unaffected

In March and again in August this year, several software parts that engineers everywhere use daily were tampered with. You do not need to write code to follow this, because it concerns the systems your company runs.

First, what a “package” is

Almost nobody writes software from scratch any more. Just as you would not fire your own bricks to build a house, engineers assemble ready-made blocks of functionality that other people wrote and shared publicly. Those blocks are called packages, and npm is the largest marketplace for them — a popular package being downloaded a hundred million times a week is ordinary.

The upside is speed. The risk is that if one brick gets swapped, every house built with it has a problem. That is a supply chain attack: the attacker does not come at you directly, they come at the parts you use.

What happened

31 March, axios. This is the package that handles network requests, downloaded around a hundred million times a week. An attacker took over a maintainer’s account and published two tampered versions carrying code that installed a backdoor on Windows, macOS and Linux. The malicious versions were live for roughly three hours, and anyone who ran a fresh install in that window picked them up. (axios post-mortem)

4 August, keyv and a batch of related packages. The attacker compromised the maintainer’s GitHub account, changed the code directly and shipped new versions. This one scans the filesystem for credentials — npm, GitHub, AWS, Stripe and Slack tokens, plus SSH keys — and then uses what it steals to infect further packages. It spread to 434 packages across 1,381 versions, together accounting for more than two billion installs a month. (Aikido Security)

In other words, this is no longer someone quietly planting a virus. It reproduces on its own.

Our products: checked, and unaffected

When the news broke we went through everything PCIRCLE operates — this site, PCircle SimpleERP and OpenBiz-Booking — comparing the versions actually installed against the affected-version lists from both incidents.

Result: none of them uses a version that carried the malicious code.

Worth being precise about: what we compared was which version is actually installed, not whether it “should be fine”. Both incidents name exact version numbers, so whether you match them is a checkable fact, not a judgement call.

Three things you can do

You do not need to read any code, but you can ask the right questions.

1. Ask your software vendor one question. “Were our systems affected by the npm incidents?” They should be able to give you a clear yes or no and say how they know. “Probably fine” is not an answer.

2. If the answer is yes, rotate every credential. Treat every password, API key and database connection string on that machine as leaked, and replace them all. Stealing exactly those was the point of the August attack.

3. Ask how they manage versions. Pinning exact versions, rather than pulling whatever is newest on every install, defeats a three-hour ambush outright — your system never reaches for the new version in the first place. It is basic practice, and not everyone does it.

This will not be the last one

The convenience of package marketplaces is real, and so is the risk, and each attack is larger than the last. The answer is not to stop using other people’s parts — nobody can. It is whether somebody is watching this on your behalf, and whether they can give you an answer within a day when something happens.

To talk through how to audit the systems you run today, the first conversation costs nothing.