The Axios supply chain incident through a risk lens

I’m sure most readers wiill have heard the cyber-security-101 advice:

Always keep your software up to date!

This post analyses a recent example of why that advice is not necessarily risk free and how it can even be dangerous if not applied with care. That being said… the advice is still generally sound, and you should still keep your software up to date!

Context

What is Axios?

In March 2026, Axios, a widely used software component for web applications, suffered a high-profile supply chain attack (Axios Incident).

Axios is an open-source JavaScript HTTP library that developers commonly use to allow web-based applications to send and receive data over the internet. For example, communicating with payment gateways, customer databases, login systems, and third-party APIs.

Axios is available on Node Package Manager (npm) and sees over 100 million weekly downloads, making it a critical piece of the web’s infrastructure. npm is a registry where developers publish and share reusable code modules (each referred to as a package). When a developer installs Axios (or any other package) via npm, they are downloading code that will run in their application.

For the technical-minded, a typical Axios implementation in code might look like this:

import axios from "axios"; // Import the axios library from node_modules
try {
  const response = await axios.get("https://api.example.com/data"); // Make a GET request to the specified URL
  // Process the response data
} catch (error) {
  // Handle any errors that occur during the request
}

How does npm work?

When a developer publishes a package to npm, they create a new version of that package. Each version is uniquely identified by a version number, following the semantic versioning convention (e.g., 1.0.0, 1.1.0, 2.0.0). Developers can then install specific versions of a package in their projects, ensuring compatibility and stability.

Just prior to the Axios Incident, the lastest versions of Axios were axios@1.14.0 (latest) and axios@0.3.0 (legacy). When updating or installing axios for the first time, the latest version is installed by default (unless otherwise specified).

Incident Summary

On or about 30 March 2026, attackers compromised the npm account of a trusted Axios maintainer, allowing them to publish a malicious version of the library.

Timeline of events

A high level timeline of the attack that occured on or about 30 March 2026 is as follows:

1. An unknown and unauthorised third party (Threat Actor) gains access to an Axios maintainer’s npm account (Compromised Account).

2. Threat Actor uses the Compromised Account to publish a malicious versions axios@1.14.1 (latest) and axios@0.3.1 (legacy) to npm (Malicious Versions). These versions contain a remote access trojan (RAT) allowing the Threat Actor to execute arbitrary code on almost any system that installs the Malicious Versions.

3. The Malicious Versions are downloaded and installed by thousands of developers and organisations worldwide, leading to widespread compromise of systems and data.

4. The attack is discovered and publicly disclosed, leading to a rush of patching and mitigation efforts by affected parties. The Malicious Versions are removed from npm, but the damage is already done.

Capabilities of the RAT

The RAT embedded in the Malicious Versions were able to perform a wide range of malicious activities, including:

• exfiltrating sensitive data (e.g., environment variables, configuration files, source code, personal information);
• installing additional malware or tools on compromised systems;
• establishing persistent access to compromised systems; and
• using compromised systems as a foothold to attack other systems.

The compromise was clearly well-planned and complex in nature. While a detailed analysis of the technicalities is outside the scope of this article, it is worth noting that the RAT was designed to be stealthy and resilient, using techniques such as obfuscation and anti-analysis measures to evade detection and analysis by security researchers and defenders. The command and control infrastructure used by the RAT was also sophisticated, serving different payloads to different victims based on factors such as the victim’s operating system and was cable of receiving updates and sending new commands from the Threat Actor.

For a detailed technical analysis of the attack, see

• Inside the Axios supply chain compromise - One RAT to rule them all published by Elastic Security Labs; and
• North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack published by Google Cloud Threat Intelligence.

Takeaways from a risk perspective

The Axios Incident is a stark reminder of the risks associated with software supply chains and the need for robust security practices and risk management in the software development ecosystem. Some of those concerns are explored below.

Open source software licenses

Use of Axios is licensed under the MIT License, a widely used open source software license. The MIT License is a permissive license that , ‘free of charge’, allows users ‘to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software’ so long as they include the original copyright notice and permission notice ‘in all copies or substantial portions of the Software’.

That flexibility is one of the reasons Axios, and many other open source software projects, have become foundational parts of modern software development. However, permissive licensing can also mean that much of the operational risk of using the software sits with the organisation choosing to deploy it.

The MIT License (as with many open source licences) includes a broad disclaimer of warranties and liabilities:

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

(emphasis added)

From a risk management perspective, this is significant. Organisations may rely heavily on open source packages for critical business functions, yet those packages may be maintained by volunteers, small teams or contributors with limited resources. If a package is compromised, abandoned or otherwise affected by a serious defect, users may have limited practical recourse and may need to absorb the cost of remediation themselves.

That does not mean open source software is inherently unsafe. In many cases, popular open source projects are robust, widely scrutinised and rapidly improved by the community. Some are even maintained by large technology companies, for example:

• React (the statistically most-popular JavaScript library for building user interfaces) is maintained by Facebook.
• TensorFlow (a widely used machine learning framework) is maintained by Google.
• Kubernetes (a leading container orchestration platform) is maintained by the Cloud Native Computing Foundation, which includes members such as Google, Microsoft, and IBM.

In short, the point is that adopting open source software should be treated as a supply chain risk decision rather than a purely technical convenience. Furthermore, organsations relying on (or intended to rely on) any software dependency should consider the legal implications of the software’s license, especially any disclaimers of warranties and liabilities.

Low risk visibility

Many organisations do not have clear visibility over the third-party software components used within their systems. Modern software is often built using numerous external libraries and tools, some of which sit several layers beneath the product(s) intentionally selected. This can mean an issue affecting one upstream provider creates broader exposure than first realised.

The Axios Incident is a practical example. A business may never have consciously selected Axios at all, yet still have been exposed because another software component depended on it. This layered chain of dependencies is often referred to as a dependency tree: one application relies on one package, which in turn relies on others.

To demonstrate this, lets consider the twilio package, a popular library for integrating with the Twilio communications platform. twilio depends on axios to make HTTP requests, meaning that any project using twilio is also indirectly using axios and therefore exposed to the Axios Incident. The dependency tree for twilio is as follows:

(graph generated using npmgraph, with thanks)

What also can be seen from the above graph is that twilio indirectly depends on mime-db which is a dependent of form-data, which is a dependent of axios, which is a dependent of twilio. That’s 4 layers of dependencies between twilio and mime-db. This highlights how complex and intertwined software dependencies can be, and how an issue in one package can have far-reaching implications across the ecosystem.

Scope of potential impact

As outlined above, the capabilities of the RAT embedded within the Malicious Versions had the potential to create serious consequences for affected organisations. Where deployed into developer environments, internal servers or production systems, the compromise may have created opportunities for:

• data theft / loss, especially concerning with respect to IP, personal and confidential information;
• credential compromise;
• further network intrusion; and
• operational disruption.

All of the above, as with any cyber incident, could have significant financial, reputational and regulatory consequences for affected organisations.

The potential scale of exposure was also substantial. Being one of the most widely used packages in the JavaScript ecosystem, Axios is incorporated into a large number of commercial products, internal business systems and development tools (both directly and indirectly through dependency trees). As a result, even a relatively short-lived compromise had the potential to affect a very large number of organisations globally, including some that may not have realised they were relying on Axios at all.

Notably, despite the apparent breadth of potential exposure, there appear to have been relatively few publicly disclosed victim organisations arising from the Axios Incident. That may reflect effective containment, limited successful exploitation, under-reporting or organisations choosing not to publicly discuss internal security events.

One prominent exception was OpenAI, which publicly disclosed that a compromised version of Axios had been downloaded and executed within a GitHub Actions workflow used in its macOS application signing process. OpenAI stated it found no evidence that user data, internal systems or software were compromised, but nevertheless rotated its code-signing certificates and required macOS users to update affected applications as a precaution.

What can organisations do to mitigate supply chain risks?

There are a range of governance and technical controls that organisations can implement at various stages of the software development lifecycle to mitigate supply chain risks. Some examples are outlined below, though this is by no means an exhaustive list.

Governance

Technical controls

In short

The Axios supply chain attack is a powerful example of the risks inherent in modern software development, where reliance on third-party components is not without consequences. It underscores the need for organisations to adopt a risk management mindset when it comes to software dependencies, including:

• understanding the legal implications of open source licenses;
• improving visibility into software supply chains; and
• implementing robust governance and technical controls to mitigate potential impacts.

It would be remiss to end without acknowledging the efforts of the security researchers and defenders who investigated and responded to the Axios Incident, as well as the broader community of open source maintainers and contributors who build and maintain the software that underpins our digital world.