In the early hours of 31 March 2026, axios, an extremely popular HTTP client for JavaScript, suffered a malicious payload injection attack. While the malicious code was removed within a matter of hours, the package’s popularity means that millions of build systems may have been infected.
This attack is the latest in a growing list of software supply chain attacks, where malicious actors take advantage of the popularity of open source packages to serve malicious payloads to millions of victims. npm credentials have repeatedly emerged as a weak point that malicious actors attack.
The attack vector appears to have been a compromise of the npm account of one of axios’s maintainers, giving a malicious actor the ability to publish new versions of axios to the npm registry and add malicious dependencies to the payload.
The malicious payload was added to two branches of axios between 00:20 and 01:00 UTC on 31 March. The malicious version remained live on npm for around 2 hours, in part because the maintainer’s npm account was the only admin account, preventing other collaborators from shutting down the attack until the case was picked up by npm’s administrators.
The attack appears designed to facilitate crypto-related fraud. The attacker modified axios@1.4.1 and axios@0.30.4, pulling in plain-crypto-js@4.2.1, which is a new malicious software package that did not exist before yesterday.
A clean decoy version of plain-crypto-js was published 18 hours before the axios updates. The compromised payload, in a new version of plain-crypto-js, deploys a remote access trojan that’s tailored for the host’s operating system. This is a textbook supply chain malware injection incident. Systems that configure their build managers to install the latest version by default are subject to compromise in this style of attack. That’s probably a huge number of systems, given that axios is a popular project, with over 100 million weekly downloads on npmjs.com.
The axios breach comes less than a week after another popular package, LiteLLM, was poisoned on PyPI, the canonical Python public registry. Very popular open source packages are an attractive attack vector for malicious actors. Once a malicious payload like this enters your software supply chain, it can do irreversible damage almost immediately. Cleanup is often a slow and frustrating process, and regulations such as DORA and the EU Cyber Resilience Act (CRA) require companies to report these incidents within 24 hours, or face substantial fines.
Here’s how to protect your software supply chain:
Route all package requests through a private registry proxy, like Cloudsmith. Sitting between your developers and public registries, Cloudsmith creates a checkpoint, applying security policies before packages reach build environments or developers’ local machines.
This proxy buffer is a key component of Cloudsmith. With Cloudsmith as your control plane, every public package, and base Docker container image, is subject to scanning and security policies before anything reaches your build systems.
Apply age-based (cooldown) policies to block newly published packages. plain-crypto-js@4.2.1 was created less than a day before the attack. It was published specifically as part of a malicious payload before the compromised axios versions were published. Blocking package versions less than 7 days old (the specific age is configurable) is one of the most effective ways to stop this class of attack, giving security researchers time to identify the vulnerability.
In 2025, 99% of malicious npm packages were identified and officially verified within 72 hours – implementing a simple cooldown policy significantly reduces the attack vector.
Cloudsmith users with a cooldown policy in place would block plain-crypto-js@4.2.1 even before malicious behavior was reported, protecting their software supply chain from this attack.
You can configure cooldown policies in many package managers, but Cloudsmith allows you to set the policy at an organizational level, so it’s enforced across formats, teams, and build systems consistently.
Subscribe to real-time threat intelligence feeds. Cloudsmith subscribes to databases like OSV.dev and the OpenSSF Malicious Packages project, which update in near real-time. axios@1.4.1 and axios@0.30.4 are currently tracked under MAL-2026-2307. Using a system like Cloudsmith to integrate these feeds into your package policies means you get automatic protection as new threats are identified.
Cloudsmith’s policy manager can act on these intelligence feeds, so anti-malware policies trigger even after the cooldown period ends. We’ve written before about how Cloudsmith’s policy manager protects your software supply chain against malicious packages.
Let’s look at an example of Cloudsmith EPM policy. This one serves as a malware detection gate. EPM runs after the Cloudsmith security scan completes during package synchronisation, making scan results available as input.v0. In this case, the policy code loops over the input.v0.osv array, which is the OSV malware data from the scan. For each vulnerability object, it checks, “does the ID start with the string MAL- ?” If yes, it adds that vulnerability.id to the malicious_packages list.
package cloudsmith
default match := false
match if count(malicious_packages) > 0
malicious_packages := [vulnerability.id |
some vulnerability in input.v0.osv
startswith(vulnerability.id, "MAL-")
]So what does this policy do in practice? It flags any package that has been reported as known malicious as part of the OpenSSF Malicious Packages project. "MAL-" is used specifically in vulnerability feeds to indicate malware-related findings. Once a match is found, Cloudsmith will execute the defined actions for this policy, such as to quarantine, tag, or block package promotion.
If you are interested in evaluating proactive security policies for poisoned/malicious software packages, talk to Cloudsmith about protecting your software supply chain from attacks like the one on axios.
Read our full incident breakdown here.
