Software Supply Chain Attack: One Email, 2B Downloads

Software Supply Chain Attack: One Email, 2B Downloads

A software supply chain attack can compromise a business without an attacker ever breaking through its firewall.

Instead, the attacker compromises something the business already trusts: an open-source dependency, software update, plugin, build tool, browser extension, or vendor account. The malicious code then arrives through the same delivery process used for legitimate software.

That risk became unusually visible on September 8, 2025, when attackers compromised the npm account of JavaScript maintainer Josh Junon, known as qix, after a phishing attack. Malicious versions were subsequently published across at least 18 widely used packages, including chalk and debug.

Those packages collectively received more than two billion downloads per week under normal conditions. That figure describes the popularity and potential reach of the affected package ecosystem; it does not mean the malicious versions themselves were downloaded two billion times. Sygnia reported that the attackers moved from account compromise to malicious package publication in roughly 16 minutes.

That distinction matters.

The real lesson from the incident is not that billions of systems were successfully infected. It is that compromising one trusted software publisher created a distribution path capable of reaching an enormous number of downstream applications.

For business owners, technical leaders, developers, and security teams, that is the central problem with software supply chain risk: trust itself becomes the attack vector.

What Is a Software Supply Chain Attack?

Most security controls are designed around the assumption that malicious activity comes from outside your trusted environment.

A supply chain attack changes that assumption.

Imagine an office with strong access control. Visitors sign in, employees use badges, and unauthorized people are stopped at reception.

But a delivery company has been bringing supplies to the building for years. Its drivers are recognized. Its boxes are expected. Nobody opens every package before allowing it through.

Now imagine an attacker takes control of that supplier and places something malicious inside the normal delivery.

The receptionist still follows procedure.

The security system still works.

The dangerous item reaches the office because it arrived through a channel everyone already trusted.

Software supply chains work in much the same way.

Modern applications rarely consist entirely of code written by one company. They depend on open-source libraries, frameworks, package registries, CI/CD actions, container images, plugins, APIs, SDKs, and third-party services.

That reuse makes modern development possible.

It also means a compromise upstream can travel downstream very quickly.

A typical software supply chain attack therefore involves three elements:

A trusted component or publisher. This might be an npm package, Python package, WordPress plugin, GitHub Action, vendor update, browser extension, container image, or another dependency.

Compromise somewhere upstream. The attacker might steal a maintainer account, obtain a publishing token, compromise a CI/CD workflow, introduce malicious code into a project, exploit dependency confusion, or take control of an abandoned package.

A downstream process that trusts the compromised source. Automated dependency updates, build pipelines, package managers, deployment workflows, and update mechanisms can distribute the altered software without requiring the attacker to compromise every customer individually.

That scalability is what makes supply chain attacks so attractive.

What Happened in the September 2025 npm Attack?

The September incident began with social engineering rather than a software vulnerability.

According to Sygnia's incident analysis, attackers registered the look-alike domain npmjs.help on September 5, 2025.

The phishing campaign impersonated npm security communications and warned maintainers that their accounts could be locked unless they updated their two-factor authentication settings.

Josh Junon entered credentials through the fraudulent page.

At approximately 13:16 UTC on September 8, the first malicious package version appeared. Sygnia's timeline places that publication roughly 16 minutes after the initial account compromise. By 19:59 UTC, npm reported that the impacted versions had been removed, with some residual cleanup continuing into September 9.

The affected packages included commonly used JavaScript utilities such as:

• chalk
• debug
• ansi-styles
• supports-color
• strip-ansi
• ansi-regex
• wrap-ansi
• color-convert
• color-name
• color-string

Aikido documented 18 heavily downloaded packages in the original campaign. Their ordinary combined download volume illustrates why a single maintainer account can represent such a large downstream trust relationship.

The attacker did not need a vulnerability in millions of downstream applications. Compromising a trusted publishing account created the distribution channel.

The "2 Billion Downloads" Number Needs Context

This is one of the most important details to understand correctly.

The affected package set had more than two billion weekly downloads collectively, depending on the source and measurement period. Some contemporary reporting calculated an even higher combined figure.

That does not translate into two billion malicious installations.

Only specific malicious package versions were dangerous, and they were available for a limited period before removal. Applications already using safe versions with deterministic dependency resolution would not automatically become compromised simply because a malicious release appeared.

Why does the large number still matter?

Because it measures potential distribution leverage.

A successful compromise of a high-trust package publisher can create access to:

• developer workstations;
• CI/CD systems;
• production builds;
• frontend applications;
• downstream libraries;
• cloud credentials;
• software vendors;
• and ultimately their customers.

The package itself may be tiny.

Its position inside the dependency graph can be enormous.

What the Malware Actually Did

The malicious payload in this incident was primarily designed to manipulate cryptocurrency transactions running in browser environments.

It intercepted browser and wallet functionality including fetch(), XMLHttpRequest, and interfaces such as window.ethereum. Researchers found logic capable of identifying cryptocurrency addresses and substituting attacker-controlled destinations.

One particularly interesting detail was the use of string similarity.

Instead of blindly substituting an obviously different wallet address, the malware could select an attacker-controlled address that resembled the intended destination. Researchers analyzing the payload described its use of Levenshtein distance, an algorithm that measures how different two strings are.

That matters because cryptocurrency users are often advised to visually compare the beginning and end of an address before approving a transaction.

The malware was designed with that human safety behavior in mind.

This is a useful defensive lesson: attackers do not only study software. They study how people verify software and transactions, then design around those habits.

This Was Not Simply Clipboard Malware

Calling the payload a "clipboard thief" oversimplifies what happened.

The important behavior was transaction and network interception inside browser contexts. The malware could manipulate information closer to the point where applications or wallets processed the transaction.

That is more dangerous than ordinary clipboard replacement because the user interface can appear trustworthy while the underlying transaction data has already changed.

Sygnia reported support for manipulation across multiple cryptocurrency ecosystems and described techniques for altering transaction parameters while attempting to preserve a legitimate appearance.

Why the Small Financial Loss Does Not Make the Incident Small

Sygnia estimated direct cryptocurrency theft associated with the campaign at approximately $500 during its analysis.

Other early on-chain analyses reported substantially lower confirmed values, illustrating how difficult it can be to measure financial impact during an active incident.

Either way, focusing only on the amount stolen misses the main security lesson.

The payload was narrow.

It targeted cryptocurrency transactions in particular execution environments. A different attacker controlling the same publishing channel could have chosen a very different objective.

For example, malicious dependency code can potentially be designed to:

• steal API keys or cloud credentials;
• read environment variables;
• access source code;
• capture CI/CD secrets;
• establish persistence;
• modify build artifacts;
• inject browser-side scripts;
• or obtain additional publishing credentials.

That is why defenders should measure a supply chain incident by the privilege and distribution path obtained, not only by the attacker's immediate revenue.

The Problem Became More Serious After the Chalk Incident

The September 2025 compromise was not an isolated warning.

Later attacks demonstrated that malicious package campaigns could become more automated.

Shai-Hulud Showed Worm-Like Propagation

The Shai-Hulud npm campaign demonstrated a particularly concerning model: compromised credentials could be used to infect additional packages and continue propagating through trusted developer infrastructure.

A later November 2025 wave analyzed by Socket affected more than 500 packages and over 700 package versions.

That changes the economics of the attack.

Traditional account compromise is linear: compromise one maintainer, attack the packages that maintainer controls.

A self-propagating supply chain attack can use one successful compromise to search for additional credentials, repositories, packages, and publishing opportunities.

AI Infrastructure Is Now Part of the Same Supply Chain

The problem is also expanding beyond traditional web-development packages.

On March 24, 2026, malicious versions 1.82.7 and 1.82.8 of the Python package LiteLLM were published to PyPI.

The affected releases contained credential-stealing capabilities and persistence mechanisms. NHS England's cyber alert confirmed both malicious versions and reported that they were subsequently quarantined. An independent analysis of PyPI download data counted approximately 47,000 downloads of the malicious versions during the exposure window.

The significance is broader than LiteLLM itself.

AI applications increasingly depend on:

• model-routing libraries;
• agent frameworks;
• MCP integrations;
• SDKs;
• vector-database clients;
• CI/CD workflows;
• package registries;
• and cloud credentials.

AI development has not escaped software supply chain risk. It has added another high-value dependency ecosystem to protect.

The Scale of Malicious Open-Source Packages in 2025

Sonatype's 2026 State of the Software Supply Chain report provides useful context.

The company reported identifying more than 454,600 new malicious packages during 2025, bringing its cumulative tracked total to more than 1.233 million packages across ecosystems including npm, PyPI, Maven Central, NuGet, and Hugging Face.

In Sonatype's 2025 dataset, more than 99% of observed open-source malware occurred on npm.

That statistic should be interpreted as Sonatype's observed dataset rather than a universal statement about every malicious open-source artifact in existence.

The report also shows why package malware should not be treated as a single threat category.

Sonatype classified 55.9% of logged malicious packages as repository abuse and 27.5% as potentially unwanted applications. More security-sensitive behaviors included host-information exfiltration at 5.7%, secret exfiltration at 3.9%, droppers or loaders at 2.7%, and backdoors at 2.1%.

The important trend is not simply package volume. Developer machines and build systems are increasingly valuable attack targets because they contain credentials and access to downstream software.

How a Supply Chain Attack Reaches a Business That Does Not Develop Software

You do not need an internal software engineering department to have software supply chain exposure.

Your Website

WordPress plugins, themes, JavaScript libraries, analytics scripts, and CMS extensions are all third-party code.

If a trusted plugin publisher is compromised, malicious code can arrive as an ordinary update.

This is one reason dependency management should sit alongside patching, access control, backups, and application security in a broader website security strategy.

Your SaaS Vendors

Your CRM, accounting platform, booking system, support desk, marketing software, and payment integrations are themselves built from dependencies.

Their software supply chain becomes part of yours.

You may never install the compromised library directly, but you still depend on the vendor controlling what enters its production environment.

Your Development Agency or Contractor

An external development company can have legitimate access to:

• your source repository;
• cloud account;
• hosting environment;
• deployment pipeline;
• DNS;
• package registry;
• API keys;
• and production application.

A compromised contractor laptop, GitHub account, deployment token, or CI/CD workflow can therefore become an indirect route into your environment.

Your Employees' Browsers

Browser extensions are another software supply chain.

Extensions can receive updates from their publishers and may have permission to interact with pages employees visit. A compromised extension with broad permissions can therefore create exposure even when the company's own software has not changed.

Six Controls That Reduce Software Supply Chain Risk

There is no single product that makes a supply chain safe.

The goal is to prevent one upstream compromise from automatically becoming a production compromise.

1. Use Lockfiles and Deterministic Builds

Package lockfiles such as package-lock.json, pnpm-lock.yaml, yarn.lock, poetry.lock, or equivalent files record resolved dependency versions.

In CI/CD environments, use installation modes designed to respect those locked versions rather than silently recalculating dependencies.

For npm projects, that commonly means using npm ci for reproducible CI builds.

A lockfile is valuable because publishing a new malicious version does not automatically change an existing locked dependency graph.

But a lockfile is not magic.

If an automated update service changes the lockfile to the malicious version and that change is approved immediately, the application can still become exposed.

The control works best when paired with review and staged dependency updates.

2. Introduce a Release-Age Buffer for Routine Dependency Updates

The first malicious packages in the September 2025 incident appeared around 13:16 UTC, and npm's removal process unfolded over the following hours.

That creates a useful defensive concept: do not automatically adopt every newly published dependency version immediately unless you have a specific reason to do so.

For routine updates, a minimum package age or controlled update window can give maintainers and security researchers time to detect malicious releases.

This is not appropriate for every situation. A critical vulnerability patch may need immediate deployment.

The point is to separate:

"A new version exists"

from:

"This version should enter production right now."

3. Maintain an SBOM or Equivalent Dependency Inventory

A Software Bill of Materials (SBOM) records the components used inside an application.

Its practical value becomes obvious during an incident.

When a security advisory names a package and version, the first question is:

Are we running it anywhere?

Without an inventory, answering that question may require manually searching repositories, applications, container images, build systems, and vendor records.

With a current dependency inventory, investigation starts from known data.

An SBOM does not itself block malware.

It gives your organization something equally important during incident response: visibility.

4. Scan Dependencies Continuously—but Do Not Depend on Scanning Alone

Software Composition Analysis and dependency-security tools can identify known vulnerable or malicious components in lockfiles and build environments.

Run these checks during:

• pull requests;
• dependency updates;
• CI builds;
• release processes;
• and scheduled security reviews.

However, scanners have a fundamental limitation.

A malicious version may initially be unknown to every security database.

The September npm incident demonstrates why controls such as deterministic builds, update staging, restricted credentials, and provenance are still necessary even when dependency scanning is enabled.

Scanning is one layer, not the whole defense.

5. Reduce What CI/CD Systems and Packages Can Access

A malicious dependency can only steal credentials that are available to its execution environment.

That makes CI/CD privilege one of the most important parts of supply chain security.

Avoid giving ordinary build jobs:

• permanent cloud administrator credentials;
• unrestricted production database access;
• long-lived deployment tokens;
• secrets unrelated to the current job;
• or broad package-publishing rights.

Prefer short-lived and narrowly scoped credentials.

For package publishers, modern registries are increasingly supporting identity-based publishing rather than permanent secrets. npm's current trusted publishing system uses OpenID Connect to issue short-lived, workflow-specific credentials, reducing reliance on long-lived npm publishing tokens. npm also recommends restricting traditional token publishing after trusted publishing has been configured.

That is an important architectural improvement: if there is no permanent publishing secret stored in CI, there is less for malware to steal.

6. Use Phishing-Resistant Authentication for High-Privilege Accounts

The September 2025 attack began with a phishing page impersonating npm.

That means authentication design matters as much as malware detection.

For accounts capable of publishing packages, deploying production software, managing cloud infrastructure, or changing CI/CD secrets, prefer phishing-resistant authentication such as properly implemented passkeys or hardware security keys using WebAuthn/FIDO2.

Traditional one-time authentication codes provide useful protection, but sophisticated phishing systems can sometimes proxy those codes in real time.

Origin-bound authentication provides stronger resistance to look-alike login sites.

Also protect the publishing path itself. npm now supports trusted publishing through OIDC, which allows CI/CD workflows to publish without maintaining a reusable npm token.

The strongest defense combines visibility, controlled change, limited privilege, and secure publishing.

What Lockfiles, SBOMs, and Scanners Actually Do

These controls are often discussed as though they solve the same problem. They do not.

Supply chain security works when these controls overlap.

If one fails, another should reduce the impact.

What to Do If You Suspect a Compromised Dependency

When a malicious package advisory appears, do not immediately rotate every credential in the company without first understanding where the package executed.

Start by determining exposure.

1. Identify the Exact Package and Version

Search:

• lockfiles;
• SBOMs;
• container manifests;
• CI logs;
• cached build artifacts;
• deployment records;
• developer environments.

A package name alone is not enough. You need the affected version and the time it entered the environment.

2. Determine Where the Code Executed

Ask whether the package ran on:

• a developer laptop;
• CI/CD;
• a production server;
• a browser bundle;
• a container-build environment;
• or nowhere at all because it was only present in metadata.

Execution context determines the likely impact.

3. Identify Accessible Secrets and Systems

If the malicious code executed inside CI, determine which credentials were available to that specific job.

If it ran in a browser bundle, investigate user-side behavior and affected sessions.

Do not assume every secret was exposed simply because a dependency appeared in a lockfile.

4. Remove the Malicious Version and Rebuild Cleanly

Use a known-good dependency version.

Recreate the environment from trusted sources rather than attempting to surgically modify a potentially compromised build artifact.

5. Rotate Credentials Based on Exposure

Rotate credentials that were accessible to the compromised environment.

Prioritize:

• cloud credentials;
• deployment tokens;
• package registry tokens;
• source-control tokens;
• signing keys;
• API keys;
• database credentials.

6. Review Logs for Follow-On Activity

Look for unexpected:

• package publications;
• repository changes;
• cloud API calls;
• new identities;
• deployments;
• workflow modifications;
• outbound connections;
• secret access;
• or authentication events.

The malicious package may be the initial entry point rather than the final objective.

Questions to Ask Your Developers and Software Vendors

You do not need to read source code to assess supply chain maturity.

Ask your critical software suppliers:

1. Can you provide an SBOM or dependency inventory for the software version we use?
2. How do you identify and respond to compromised dependencies?
3. Do production builds use deterministic dependency resolution and committed lockfiles?
4. How are package updates reviewed before reaching production?
5. What credentials are available to your build pipelines, and are they short-lived and scoped?
6. Do package publishing and production deployment require phishing-resistant authentication or an equivalent secure publishing mechanism?
7. How would you notify us if a third-party component used by your product were compromised?
8. Have you tested your response to a software supply chain incident?

The quality of the answers matters more than whether the vendor can say "yes" to everything.

A mature supplier should be able to explain its process clearly.

If nobody can determine which dependencies are inside the product, incident response will begin with inventory discovery instead of containment.

A Practical One-Hour Supply Chain Review

A small business does not need to launch a six-month security program to improve visibility.

Start with one hour.

First 15 Minutes: Identify Critical Software

List the software that can reach your most important systems or data.

Include:

• website and CMS;
• cloud infrastructure;
• CRM;
• accounting software;
• payment systems;
• internal communication;
• browser extensions;
• custom applications;
• and external development providers.

Next 15 Minutes: Map Access

For every critical system, record what it can access.

Examples:

Website plugin → website database and customer sessions CRM → customer information and email Development agency → GitHub, hosting and deployment access CI/CD system → cloud infrastructure and production deployment Browser extension → webpages viewed by employees

This turns a software list into a risk map.

Next 15 Minutes: Review High-Privilege Identities

Identify who can:

• deploy production code;
• publish packages;
• modify build workflows;
• change cloud infrastructure;
• manage website plugins;
• or access deployment secrets.

Check whether those accounts use strong, phishing-resistant authentication where supported.

Final 15 Minutes: Choose Your Two Biggest Unknowns

Perhaps you do not know what dependencies your agency uses.

Perhaps nobody has reviewed browser extensions.

Perhaps a CI/CD environment still contains a permanent cloud administrator key.

Choose the two highest-impact unknowns and assign an owner and deadline.

That produces something more useful than a generic security checklist: an actual list of decisions that need to be made.

Supply Chain Risk Is Also a Governance Problem

Technical controls fail when ownership is unclear.

A common organization may have:

• IT responsible for endpoints;
• developers responsible for application code;
• DevOps responsible for deployment;
• procurement responsible for vendors;
• security responsible for monitoring;
• and business leadership responsible for risk.

Software dependencies sit between all of them.

Someone should own the question:

What third-party software do we depend on, what can it reach, and who has authority to change it?

That owner does not need to manually approve every library update.

Their role is to ensure the organization can answer basic questions quickly when an incident occurs.

Good governance means knowing:

• what software matters;
• who owns it;
• which suppliers support it;
• what privileges it has;
• how updates are controlled;
• and how the organization would respond to compromise.

When an urgent advisory arrives, those records save time.

Regulatory Reporting Makes Visibility More Important

For some organizations, fast incident understanding is not optional.

Under the EU's Digital Operational Resilience Act (DORA) reporting rules for major ICT-related incidents, an affected financial entity must submit its initial notification as early as possible and, in any event, within four hours after classifying the incident as major and no later than 24 hours after becoming aware of the incident.

Under NIS2, covered essential and important entities must provide an early warning without undue delay and within 24 hours of becoming aware of a significant incident, followed by an incident notification within 72 hours.

Whether a particular dependency compromise triggers those obligations depends on the entity, jurisdiction, incident severity, and applicable legal requirements.

The security lesson is simpler:

You cannot assess the impact of a compromised component quickly if you do not know where that component exists.

Why Software Supply Chain Risk Cannot Be Eliminated

The answer is not to stop using open source.

Modern software depends on code reuse because rebuilding every component internally would be slower, more expensive, and often less secure.

The objective is to remove uncontrolled trust.

A mature software delivery process assumes that:

• a maintainer account can be phished;
• a package can be compromised;
• a CI/CD token can leak;
• an update can contain malicious code;
• and a security scanner may not recognize a new attack immediately.

The architecture should therefore prevent one failure from becoming unrestricted access to everything downstream.

That is the same principle used throughout security engineering:

assume individual controls can fail and design the system so failure remains contained.

Frequently Asked Questions

What is a software supply chain attack in simple terms?

A software supply chain attack compromises software, infrastructure, or a supplier that an organization already trusts. Malicious code then reaches victims through legitimate mechanisms such as package installation, software updates, plugins, CI/CD workflows, or vendor deployments.

Was the September 2025 npm attack downloaded two billion times?

No.

The affected packages collectively had more than two billion weekly downloads under normal conditions. The malicious versions were available only during a limited exposure period. The large number describes the potential reach of the compromised dependency ecosystem, not the number of confirmed malicious installations.

How did the attackers compromise the npm packages?

The incident began with a phishing campaign targeting maintainer Josh Junon. Attackers used a look-alike npm domain and subsequently obtained access to his publishing account, allowing malicious package versions to be released.

What did the malicious npm code do?

The payload primarily targeted cryptocurrency transactions in browser environments. Researchers documented interception of network and wallet APIs, replacement of transaction destinations, and techniques for choosing visually similar attacker-controlled wallet addresses.

Does a lockfile prevent supply chain attacks?

A lockfile reduces the risk of silently receiving an unexpected dependency version because it records specific resolved versions.

It does not prevent every supply chain attack. A malicious version can still enter the lockfile during an approved or automated dependency update.

Is an SBOM enough to secure the software supply chain?

No.

An SBOM provides inventory and visibility. It helps determine whether an affected component exists in your software, but additional controls are required to prevent, detect, and contain malicious dependencies.

Can antivirus detect a malicious software dependency?

Sometimes, but antivirus should not be treated as the primary defense.

Supply chain malware may execute inside build systems, developer environments, containers, browsers, or trusted processes. Effective protection therefore combines dependency analysis, behavioral detection, deterministic builds, access control, CI/CD security, and incident monitoring.

Are businesses without developers still exposed?

Yes.

Third-party SaaS providers, WordPress plugins, browser extensions, development agencies, desktop applications, and vendor updates all create software supply chain relationships.

Your organization does not have to develop software to depend on software suppliers.

The Practical Takeaway

The September 2025 npm incident matters because of what the attacker did not need.

They did not need to discover a vulnerability in millions of applications.

They did not need to compromise every company individually.

They did not need to defeat every downstream firewall.

They needed control of a trusted software publishing identity.

From there, the existing software distribution system provided the scale.

That is why software supply chain security should focus on controlling trust:

Know what you depend on. Control when dependencies change. Limit what build systems can access. Secure the identities that can publish and deploy. Keep enough inventory to respond quickly when something upstream fails.

The next malicious package may be discovered quickly.

The important question is whether your organization can determine—in minutes rather than days—whether it reached you.

Review Your Software Supply Chain Exposure

If you need help identifying weaknesses across your applications, infrastructure, third-party software, or access controls, xCyberSecurity provides cybersecurity risk-assessment and consulting services.

Request a Risk Assessment: xcybersecurity.io/assessment

Talk to a Cybersecurity Expert: xcybersecurity.io/contact

Explore xCyberSecurity Services: xcybersecurity.io/services

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): [xcybersecurity.io](https://www.xcybersecurity.io