In late March 2026, a significant software supply chain attack targeting the widely used Axios NPM package moved from suspicion to attribution. What initially appeared to be a routine package compromise quickly escalated into a coordinated campaign, with multiple security researchers and intelligence teams linking the activity to a North Korean threat actor.
The interesting questions are always the same: how the package was modified, what the malicious code actually does, where the trust boundary is crossed, and how downstream systems become exposed. This post breaks down the Axios supply chain attack in those terms.
What is Axios and why does it matter for software supply chain security?
Axios is a promise-based HTTP client for JavaScript, commonly used to make requests from browsers and Node.js applications. Put simply, it’s the bit of code developers reach for when they need to call APIs, fetch data, or integrate external services.
Because of that, it ends up everywhere. Front-end apps use it to talk to backends, backend services use it to call other APIs, and it often gets pulled in indirectly through other dependencies. In many projects, developers may not even realise they’re using it because it sits further down the dependency tree.
That level of adoption is what makes it attractive from an attacker’s point of view. Compromising a package like Axios is not about a single target. It’s about gaining a foothold across a wide range of environments, from developer machines through to CI pipelines and production systems.
How did the Axios npm supply chain attack happen?
On 31 March 2026, the attacker pushed compromised releases of Axios to npm, specifically versions 1.14.1 and 0.30.4. These versions introduced a malicious dependency named plain-crypto-js, which was not part of the legitimate package.
Axios is one of the most widely used JavaScript libraries for handling HTTP requests, with these versions typically seeing tens of millions of weekly downloads. That level of adoption meant the malicious update had the potential to spread quickly across a large number of environments.
The injected dependency functioned as an obfuscated dropper. Once executed, it deployed the WAVESHAPER.V2 backdoor across Windows, macOS, and Linux systems. This made the attack both cross-platform and capable of establishing persistent remote access in developer machines, CI pipelines, and production environments.
At a high level, the attack itself is simple. Malicious versions of a trusted package were published and then pulled in through normal installation workflows. There was no exploit in Axios as a library. Instead, the attacker relied on the trust developers place in package registries and automated dependency resolution. Once those versions were accepted into a build or deployment pipeline, the attacker gained code execution within that environment.
What malicious code did the attackers inject into Axios?
Analysis of the compromised versions shows that the injected code was not trivial. The modifications were designed to establish persistence and enable remote access.
The key behaviours observed include:
- Execution of obfuscated JavaScript during package initialisation
- Retrieval of secondary payloads from attacker-controlled infrastructure
- Deployment of a remote access trojan (RAT)
- Environment-aware execution to avoid detection in analysis sandboxes
The important point is that this was not just data exfiltration or credential harvesting. The payload provided ongoing control of affected systems. Once executed, it allowed the attacker to interact with the host, run commands, and potentially move laterally within a network.
That shifts the incident from a dependency integrity issue into a full compromise vector.
Where the trust boundary fails
As with most supply chain attacks, the critical failure is not in application logic but in trust propagation.
Developers implicitly trust:
- The NPM registry to serve authentic packages
- Package maintainers to control release integrity
- Dependency trees to resolve safely through automation
The attack breaks that chain at the registry level. Once a malicious version is published under a trusted package name, every downstream system that installs it inherits that trust without verification.
This is particularly problematic in modern CI/CD environments, where dependencies are installed automatically and where build systems run with elevated permissions or access to secrets.
Put plainly, the attacker’s code runs in environments that often have access to API keys, cloud credentials, internal services, and deployment infrastructure; increasing the impact of this attack.
Attribution to a North Korean threat actor
Multiple sources, including Google’s threat intelligence team and reporting from Axios itself, have linked the activity to a North Korean state-sponsored group.
This attribution is not based on a single indicator. It comes from a combination of Infrastructure overlap with known campaigns, along with tactics and targeting patterns consistent with previous North Korean supply chain operations.
North Korean actors have a well-documented history of targeting software supply chains, particularly where access can lead to financial gain or high-value infrastructure compromise. Previous campaigns have focused on cryptocurrency platforms, developers, and open-source ecosystems. The Axios incident fits that pattern.
Why are npm supply chain attacks so effective in 2026?
The effectiveness of this attack comes down to scale and invisibility.
Firstly, scale. Axios is deeply embedded across the JavaScript ecosystem. A single compromised package version can propagate into web applications, backend APIs and serverless functions.
Second, invisibility. There was no user interaction required. The attack triggers during normal development or deployment workflows. From the perspective of the affected system, nothing unusual is happening. Dependencies are installed, code runs, and the application behaves as expected, at least initially. This combination makes detection difficult. Traditional endpoint security controls are not always tuned to monitor build environments or dependency installation processes.
Delivery, execution, and impact
The delivery mechanism in this case is the NPM registry itself, where malicious versions of the Axios package were published and then consumed through entirely normal installation workflows. From a developer or pipeline perspective, nothing appears out of the ordinary. The execution point occurs as soon as the package is installed or imported, at which stage the injected code runs within the context of the application or build process. This is where the trust boundary is crossed. Organisations implicitly trust third-party dependencies, and that trust allows external code to execute with the same privileges as the host environment.
The impact varies depending on where that code runs. On developer machines, it can lead to credential theft or full local compromise. Within CI/CD pipelines, it may expose sensitive secrets, tokens, or deployment keys. In production environments, it can enable persistent remote access and provide a foothold for lateral movement across systems. The critical point is that no vulnerability in the target application is required. The dependency itself becomes the execution vector, turning standard development behaviour into an entry point for compromise.
Why traditional defences struggle
Many organisations centre their security efforts on vulnerability management, focusing on patching known CVEs and scanning for outdated libraries. That approach, while necessary, does not fully address this type of threat. In this case, the dependency can appear completely current and compliant, yet still be malicious. Traditional controls are therefore looking in the wrong place.
Signature-based detection also struggles to keep pace. The payload may be obfuscated, making static analysis unreliable, while attacker infrastructure can change quickly enough to evade blocklists. In some cases, malicious behaviour is delayed or only triggered under specific conditions, further reducing the chances of early detection. The result is an attack that sits uncomfortably between software integrity and runtime security, exploiting the default assumption that third-party dependencies are inherently trustworthy.
Operational meaning
Operationally, this represents a high-impact software supply chain compromise with broad reach across the ecosystem. It is not confined to a particular platform or framework. Any system that installs the affected versions of Axios should be considered potentially exposed.
For defenders, the priority goes beyond simply identifying whether Axios is present in the environment. What matters is understanding how and where it was used. That includes determining which versions were installed, when those versions entered the environment, and the execution context in which they ran. It is equally important to assess whether any suspicious outbound connections or follow-on processes occurred after installation. This is especially relevant for build systems and CI environments, which are often under-monitored yet hold high-value credentials and access to production infrastructure.
Mitigation and defensive considerations
There is no single control that fully mitigates this class of attack, but several measures can meaningfully reduce exposure. Pinning dependencies to known-good versions limits the risk of silently ingesting malicious updates, while integrity verification through checksums or signed packages adds an additional layer of assurance. Monitoring outbound network traffic from build and development environments can help surface unexpected behaviour, particularly during dependency installation or initial execution. Restricting access to sensitive credentials at these stages further reduces the potential impact if compromise does occur. Where feasible, allow-listing trusted package sources and maintainers can also reduce the attack surface.
More broadly, organisations need to shift their trust model. Third-party dependencies should be treated as untrusted input rather than implicitly safe components. The assumption that widely used packages are inherently trustworthy is no longer sustainable in the face of increasingly targeted supply chain attacks.
Conclusion
The Axios supply chain attack is not just another NPM incident. It is a clear example of how modern software development practices can be turned into attack vectors.
The mechanism is simple. A trusted package is modified. That modification propagates automatically into countless environments. The attacker gains execution without exploiting a single vulnerability in the target application.
What makes this incident important is not just the attribution to a North Korean threat actor, but the clarity of the failure mode. Trust is extended too far, too automatically, and without sufficient verification.
Once that is understood, the lesson is straightforward. The security boundary is not just your application code. It includes every dependency you install and every system that processes them.
Resources
Axios – North Korean hackers implicated in major supply chain attack
Malwarebytes – Axios supply chain attack chops away at npm trust