Software Supply Chain Attack: One Email, 2B Downloads

A software supply chain attack is one where nobody breaks into your company. Instead, someone poisons a piece of software you already trust — a library your developers install, an update your vendor ships, a plugin on your website — and your own systems carry the damage inside for them.

On 8 September 2025 this stopped being a theoretical worry for the JavaScript world. Eighteen small utility packages, downloaded more than two billion times a week between them, were quietly replaced with versions that stole cryptocurrency. The way in was not a clever exploit. It was one email.

This explainer is written for people who sign the cheques rather than write the code. By the end you will know how these attacks work, why the software industry keeps repeating this mistake, and the six controls that actually reduce your exposure.

The Delivery Driver Nobody Checks

Picture a busy office with a strict front desk. Visitors sign in, badges get checked, the security guard knows the regulars. Now picture the delivery driver who comes twice a day with supplies. Nobody stops him. He has been coming for years, he wears the right uniform, and the boxes look the same as always.

One morning someone steals that uniform and swaps the contents of the boxes. The front desk works perfectly, the guard does his job, and the poisoned supplies still reach every desk in the building — because the whole system was built on the assumption that the delivery driver is who he says he is.

Modern software is assembled from thousands of those deliveries. A typical business web application pulls in hundreds of small open source components, and each of those pulls in others. Your developers wrote maybe five per cent of the code running your site. The rest arrived in boxes.

That is the shape of a supply chain attack. The attacker does not fight your firewall. They stand in the delivery queue.

What a Software Supply Chain Attack Actually Is

Three ingredients make one work.

A trusted supplier. An open source package, a vendor's software update, a browser extension, a WordPress plugin. Something you install without a second thought because you have installed it a hundred times.

A compromise upstream. The attacker gets control of that supplier — usually by stealing an account rather than by finding a bug. Phishing a maintainer, buying an abandoned package, or slipping malicious code into a project that accepts contributions from strangers.

Your own automation. Your build server, your update process, your npm install or composer update, faithfully fetches the newest version and runs it. The delivery arrives, and nothing in your defences was designed to question it.

The last ingredient is what makes these attacks efficient. One compromised supplier reaches every customer at once, at machine speed, through a channel every organisation has deliberately left open.

What Happened on 8 September 2025

The timeline is short enough to read in a minute, and every step is worth understanding.

A developer named Josh Junon — known online as qix — maintains a set of small JavaScript utilities. One is called chalk, which colours text in a terminal window. Another is called debug. They sound trivial, and they are trivial, which is exactly why almost every Node.js command-line tool on earth depends on them.

He received an email saying his npm account would be locked unless he refreshed his two-factor authentication. The link pointed to npmjs.help, a domain registered three days earlier that looks close enough to the real npmjs.com to pass a glance. He entered his credentials.

According to the incident analysis published by security firm Sygnia, the attackers moved from account access to publishing malicious code in roughly sixteen minutes, across at least eighteen packages with more than two billion combined weekly downloads. The poisoned versions stayed available from about 13:16 to 19:59 UTC — a little over six hours before the last one was pulled.

Four steps, sixteen minutes. No software vulnerability was exploited at any point.

The Payload: A Thief That Edits Your Clipboard

The malicious code was a crypto clipper — malware that waits for someone to send cryptocurrency and silently changes the destination.

It hooked into the browser functions that web pages use to make requests and to talk to crypto wallets, then watched for a transaction. At the moment of sending, it replaced the recipient's wallet address with one belonging to the attackers.

Here is the detail that shows real craft. Wallet addresses are long strings of random characters, and the one thing a careful user does before hitting send is glance at the first and last few characters. So the malware did not pick a random attacker address. It used the Levenshtein distance algorithm — a standard way of measuring how similar two strings are — to choose the attacker address that looked most like the intended one.

That single design decision turns a user's safety check into theatre. Our team rates this as the most instructive part of the whole incident: the attackers assumed a human would look, and engineered specifically to defeat looking.

Why "Only $500" Is the Wrong Way to Read It

The attack made almost no money. Sygnia's analysis puts direct losses at roughly $500 in cryptocurrency, and other early reports quoted figures as low as fifty dollars. The community spotted the packages fast, and the payload only targeted crypto users, a small slice of everyone who installed it.

Reading that as a happy ending would be a mistake, for three reasons.

The reach was total, the payload was narrow. Millions of installs happened in those hours, across continuous integration pipelines, developer laptops and production build servers. Everyone got the delivery. Only crypto users were robbed, because that is all the attacker asked the code to do. The same access could have exfiltrated environment variables, cloud keys or customer data.

The entry cost was near zero. One look-alike domain and one convincing email. Nothing about that requires funding, sophistication, or a nation state.

The pattern scaled almost immediately. Later in 2025 a self-replicating worm known as Shai-Hulud compromised more than 500 packages in days by using each stolen credential to publish further poisoned packages — an attack that spreads itself instead of waiting for a human to phish the next maintainer.

The Numbers That Should Change Your Budget

Sonatype's 2026 State of the Software Supply Chain Report puts the scale in context. During 2025 the company identified more than 454,600 new malicious packages, bringing the cumulative total it tracks to over 1.23 million across npm, PyPI, Maven Central, NuGet and Hugging Face.

More than 99 per cent of that open source malware appeared on npm — the same registry the chalk incident hit. Not because JavaScript developers are careless, but because npm is the largest, most automated, most interconnected registry in existence, which makes it the highest-yield place to stand in the delivery queue.

Sonatype's 2026 report. The volume is now automated: one campaign published 150,000 malicious packages in a couple of days.

The report's breakdown of what that malware does is useful for anyone deciding where to spend. Repository abuse accounts for 55.9 per cent, unwanted applications 27.5 per cent, stealing information about the host machine 5.7 per cent, stealing secrets such as API keys 3.9 per cent, droppers and loaders 2.7 per cent, and backdoors 2.1 per cent.

Those last four categories are the ones that end up in a breach notification. Roughly one in seven malicious packages is built to take something from you or to keep a door open.

This is also reaching artificial intelligence tooling. The OWASP GenAI Security Project reported that a compromised version of LiteLLM, a popular library for connecting applications to language models, was downloaded around 47,000 times during a three-hour window in March 2026. Every new ecosystem repeats the lesson.

How This Reaches a Business That Writes No Code

Most owners reading this do not employ JavaScript developers, and conclude the problem belongs to someone else. Four paths say otherwise.

Your website. WordPress plugins and themes are a supply chain. A plugin sold to thousands of sites, then bought or breached, is the same attack with a different registry. We have written before about layered website defence in our 2026 website security guide, and dependency hygiene belongs in that stack.

Your software vendors. The accounting package, the CRM, the booking system — each is built the way described above. Their exposure becomes yours the moment they ship an update, and you will hear about it after the fact.

Your agency or contractor. If an outside team builds and deploys your application, their laptops and build pipelines are part of your attack surface. A stolen token on a contractor's machine reaches your production environment.

Your browser. Extensions update automatically and can read the pages your staff are looking at, including internal dashboards and email.

The framework version of this is dependency risk, and it produces genuine emergencies. A single flawed component can hand an attacker remote code execution across every application that includes it, as we covered in the React Server Components CVSS 10 flaw.

Six Controls That Actually Work

No control stops a poisoned package from existing. These six stop it from reaching production, or limit what it can do when it does.

1. Pin versions and commit the lockfile

A lockfile records the exact version of every component your application uses, down to the components of components. With one committed, a build produces the same result today and next month, and a malicious version published an hour ago does not silently enter your product. Ask your developers one question: does our build use a committed lockfile, and does the build fail if the lockfile changes unexpectedly?

2. Delay updates by a few days

The chalk packages were pulled within about six and a half hours. A rule that says "no dependency published in the last 72 hours goes into our build" would have avoided the entire incident at zero cost. Some registries and build tools support this as a setting; where they do not, a scheduled update window achieves the same thing.

3. Keep an inventory: SBOM

A software bill of materials lists every component in a piece of software, the way an ingredients label lists what is in a packaged food product. Without one, the question "are we affected?" takes days of guesswork. With one, it takes a search. Regulators increasingly expect this, and enterprise customers increasingly ask for it during procurement.

4. Scan continuously, not annually

Software composition analysis tools compare your inventory against databases of known-bad components and alert when one of yours turns up. The alerting matters more than the scanning: an annual report tells you about an incident that finished months ago.

5. Give the build pipeline the least access it needs

The most damaging version of this attack steals what the build environment can reach. A pipeline holding a long-lived cloud administrator key turns a bad package into a full compromise. Short-lived credentials, scoped to one job, keep the blast radius small.

6. Protect maintainer and developer accounts with phishing-resistant MFA

The whole incident started with credentials typed into a look-alike domain. Hardware security keys and passkeys do not authenticate to the wrong domain, which is precisely the failure that happened here. Codes from an authenticator app can still be phished; keys cannot.

Hand this list to whoever builds or maintains your software.

If you would rather have a professional team map your dependency exposure and vendor risk, xCyberSecurity starts with a free initial review — xcybersecurity.io/assessment.

What to Ask Your Vendors and Your Developers

You do not need to read code to run this conversation. Six questions, in writing.

1. Do you produce a software bill of materials for the version we are running, and can we have it?
2. How quickly do you patch a component after a vulnerability is disclosed, and how do you notify us?
3. Do your build systems use pinned versions and committed lockfiles?
4. Is multi-factor authentication with hardware keys required for everyone who can publish or deploy?
5. What access do your build pipelines have to our production data, and for how long do those credentials live?
6. Have you been affected by a supply chain incident in the last two years, and what changed afterwards?

A supplier who answers all six has thought about this. A supplier who cannot answer question one has no inventory, which means they cannot tell you whether the next incident affects you.

A One-Hour Audit You Can Run This Week

Set aside an hour and produce a single page.

First fifteen minutes: list your software suppliers. Every system that updates itself — website plugins, desktop applications, SaaS platforms, browser extensions your staff installed. Name an owner for each.

Second fifteen minutes: mark what each one can reach. Customer data, payment systems, internal email, production servers. Anything touching two or more moves to the top.

Third fifteen minutes: check the accounts that can publish. Who at your company or agency can push an update to your website or application? Confirm each of those accounts uses a hardware key or passkey, not an SMS code.

Final fifteen minutes: send the six questions to your two most critical vendors and to whoever maintains your website.

The output is a page listing your suppliers, their access, and two open requests. That page is also the artefact an auditor or an enterprise customer asks for, which makes the hour pay for itself twice.

Why This Problem Will Not Be Solved

Open source is not going away, and neither is the model that makes it work: millions of small components, maintained largely by volunteers, wired together automatically. The efficiency of that arrangement is precisely why every business can afford software at all.

Registries are adding defences — mandatory two-factor for high-traffic packages, provenance records that prove which source code a published package came from, better anomaly detection. Each one raises the cost of the attack, and none removes it. The attacker only needs the next maintainer, on the next tired morning, with the next convincing email.

Treat it the way you treat fire. Nobody eliminates fire; buildings get sprinklers, fire doors and drills so that one ignition does not take the whole structure. Lockfiles, delayed updates, inventories and least-privilege pipelines are the fire doors of software delivery.

Who Owns This Risk Inside Your Company

Supply chain incidents fall into an ownership gap, and the gap is why so many organisations do nothing until an advisory lands.

Your IT team owns endpoints and networks. Your developers or agency own the code. Procurement owns the vendor contracts. Nobody owns the question "what components are inside the things we run, and who can change them?" — so it goes unanswered until a journalist or a customer asks it.

Fixing that is an afternoon of governance rather than a project. Name one person as the owner of the software inventory. Give them the authority to ask suppliers the six questions above and to require an answer before renewal. Put the inventory itself somewhere boring and durable: a spreadsheet with one row per supplier, the version you run, who can push updates, and what data that software can reach.

The reason to write it down is speed. When the next advisory names a package, the organisations that respond in an hour are the ones that already knew what they had. Everyone else spends two days building the list under pressure, which is the worst possible time to build it.

There is a commercial reason as well. Enterprise procurement teams and cyber insurers now ask about dependency management and patch timelines as standard, and a business that can produce an inventory and a patch policy clears those reviews faster. One page can be the difference between a deal sitting in security review and a deal that closes, because the buyer's risk team stops having to guess.

For regulated businesses the clock is explicit. Under DORA, financial entities in the EU report major incidents on an initial deadline measured in hours; NIS2 sets a 24-hour early-warning window for essential and important entities. A poisoned dependency that touches customer data starts those timers whether or not you knew the component was there.

Frequently Asked Questions

What is a software supply chain attack in simple terms?

A software supply chain attack is one where an attacker compromises something you already trust and install — an open source component, a vendor update, a plugin — so that your own systems download and run their code. Nobody breaks through your defences; the malicious code arrives through a door you deliberately keep open.

Are we at risk if our company does not build software?

Yes, indirectly. Your website plugins, your business applications and your browser extensions all update themselves from suppliers who build software this way. Your exposure runs through your vendors, so vendor questions and update discipline are the controls that matter most for you.

Does antivirus stop supply chain attacks?

Rarely. The malicious code arrives as a legitimately signed, correctly delivered update from a source your systems are configured to trust, and it often runs inside a build process rather than on a user's desktop. Detection has to happen at the dependency layer, through inventories and composition analysis.

What is an SBOM and do we need one?

A software bill of materials is a machine-readable list of every component inside a piece of software. You need one for anything you build, and you should ask for one from vendors of anything critical you buy. Without it, answering "does this incident affect us?" takes days instead of minutes.

How did attackers make only $500 from two billion downloads?

The payload targeted only cryptocurrency transactions, which few of the affected users were making during the six-hour window, and the community removed the packages quickly. The low figure reflects a narrow payload and a fast response, not a limit on what that level of access could have achieved.

Protect Your Business Today

Don't wait for a breach. xCyberSecurity provides enterprise-grade protection for businesses of all sizes.

• Get Free Assessment: xcybersecurity.io/assessment
• Talk to an Expert: xcybersecurity.io/contact
• Email: security@xcybersecurity.io
• View Services: xcybersecurity.io/services

Part of the Mejba Ahmed brand family: mejba.me · ramlit.com · colorpark.io