A comprehensive deep-dive into the dual Axios security crises of 2026 the CVE-2026-40175 remote code execution vulnerability (CVSS 9.9) that bypasses AWS IMDSv2 protections, and the March 31 North Korean-attributed supply chain attack that poisoned npm with a cross-platform Remote Access Trojan. Covers the full attack mechanics, affected versions, real-world impact and what every developer must do immediately.
Axios Under Attack : What Happened
There are roughly two million npm packages in existence. Among them, very few have achieved the kind of quiet ubiquity that Axios has. It is not a framework, not a runtime and not a platform it is a simple promise-based HTTP client that helps developers make web requests.
And yet with over 100 million weekly downloads and it sits somewhere deep inside the dependency tree of almost every modern web application on the planet. Banks and Hospitals use it. Government portals use it. Startups and trillion-dollar corporations alike have trusted it for years without a second thought. That trust as April 2026 has made clear is now under severe strain.
In the span of just fifteen days between March 30 and April 13, 2026 Axios became the center of not one but two distinct security crises. The first was a surgical, state-sponsored supply chain attack linked to North Korea that slipped a Remote Access Trojan into two freshly published npm versions and had a live window of only three hours before being suddenly.
The second is a freshly-disclosed critical vulnerability tracked as CVE-2026-40175 that scores a near-perfect 9.9 on the CVSS scale and allows attackers to escalate a seemingly minor JavaScript flaw elsewhere in a software stack into full remote code execution or complete cloud infrastructure compromise. Understanding both requires understanding how deeply Axios has embedded itself and how that depth became a responsibility.
From Library to Core Infrastructure
Axios was first published in 2014 as an elegant solution to the awkward XML HttpRequest API that developers wrestled with in early JavaScript. It was isomorphic meaning the same code ran seamlessly in both browsers and Node.js server environments and it worked with Promises out of the box, long before async/await was standard.
It became the go to answer for millions of developers asking the most basic question in web development How do I fetch data? Over time, it accumulated features quietly and reliably. Interceptors, automatic JSON transformation, request cancellation and timeout handling. All of it just worked, and nobody questioned it.
By 2026 Axios was not just popular it was structural. According to security firm Trend Micro, Axios dependencies appear in CI/CD pipelines at financial institutions, government agencies and cloud-native startups without any human actively choosing to install it.
It arrives as a transitive dependency something your package depends on or something that something else depends on. This is precisely what made the March 2026 attack so alarming. The attacker did not need to trick anyone into explicitly installing a malicious package. They simply needed to compromise the person with the keys to the front door.
Supply Chain Attack : Precision Strike
On March 30, 2026, at 05:57 UTC an attacker published a new npm package called [email protected]. It was clean no malicious code and nothing to trigger automated scanners. This was deliberate. The attacker was seeding registry history and building a paper trail for a package that would later be the weapon.
Eighteen hours later at 23:59 UTC they published [email protected] this time with a malicious payload hidden inside a postinstall hook. Then, just twenty-two minutes after that at 00:21 UTC on March 31 two new versions of Axios itself appeared on the npm registry [email protected] tagged as latest and [email protected] tagged as legacy. Both silently imported the poisoned plain-crypto-js package that existed solely to execute the attack.
The attacker had compromised the npm account of jasonsaayman one of Axios primary maintainers and the person responsible for legitimate publishes of the library. The takeover was invisible to anyone looking at the GitHub repository because the attack bypassed GitHub Actions entirely.
Every previous legitimate Axios release had been published through a cryptographically verified OIDC Trusted Publisher flow tied to GitHub Actions with provenance attestations confirming the exact commit and workflow that triggered the publish.
The malicious versions were published directly from the command line using a stolen npm token, leaving no trace in the GitHub repository’s history. The only forensic signal visible from the outside was a subtle change in the maintainers email address in the npm registry metadata from a Gmail address to a Proton Mail address that most developers would never think to check.
The npm registry treats a valid token as the sole authentication boundary for publishing. If that token is compromised no amount of upstream CI/CD hardening signed commits, branch protection rules or required reviews can prevent a malicious publish.
Once installed, the malicious postinstall hook contacted a live command-and-control server at sfrclak[.]com:8000 and delivered platform-specific second-stage payloads targeting macOS Windows and Linux separately with purpose-built Remote Access Trojans.
The malware then performed a remarkable act of self-preservation through concealment after executing, it deleted itself and replaced its own package.json with a clean decoy erasing forensic evidence and making it appear as though nothing unusual had ever been installed. Infected machines were left with persistent remote access to the attacker credentials stolen, environment variables exfiltrated and no obvious trace of how it happened.
The exposure window was remarkably short from 00:21 to 03:15 UTC on March 31, roughly three hours before Elastic Security Labs detected the anomaly through automated supply chain monitoring and filed a GitHub Security Advisory, prompting npm administration to remove the compromised versions.
But three hours is a long time when you have 100 million weekly downloads and millions of automated CI/CD pipelines running npm install continuously around the clock. Any project using a caret range such as 1.14.0 in its package.json which is the default behavior npm encourages would have silently pulled the poisoned 1.14.1 during that window without any human intervention.
Microsoft Threat Intelligence attributed the attack to Sapphire Sleet a North Korean state-sponsored actor. SANS researchers noted that the Axios compromise followed the same fingerprint as a broader campaign called TeamPCP which had compromised four other open-source packages in the preceding two weeks.
The Trivy vulnerability scanner and the KICS infrastructure scanner, and two PyPI libraries using the same technique of harvesting cloud credentials and CI/CD secrets before selling that access to other threat actors as an Initial Access Broker. The Axios attack was not an isolated opportunistic hack. It was the largest blast radius node in a coordinated campaign against the software supply chain.
CVE-2026-40175 The Vulnerability That Needs No Malware
The supply chain attack was neutralized relatively quickly. CVE-2026-40175 is a different beast entirely, and in many ways a more dangerous one. Where the supply chain attack required the attacker to first compromise a human maintainer this vulnerability requires nothing but the presence of Axios itself in your project and a single common widely-accepted JavaScript flaw anywhere else in your dependency tree.
No social engineering. No stolen credentials. No three-hour window. Just a configuration that exists in millions of production applications right now and combined with a class of vulnerability so common in JavaScript that security researchers have written papers about its prevalence for years.
The flaw was discovered by security researcher raulvdv and subsequently detailed publicly by jasonsaayman yes the same maintainer whose account was compromised in the supply chain attack now contributing in the opposite direction.
The core of the issue lives in the header processing code within Axioss lib/adapters/http.js file, specifically in how the library handles and merges configuration objects before making outbound HTTP requests.
The root problem is a complete absence of sanitization for HTTP header values classified under CWE-113 (Improper Neutralization of CRLF Sequences in HTTP Headers). On its own this is a meaningful but bounded flaw. What transforms it into a critical one is the way it combines with other common components in the JavaScript ecosystem.
The Gadget Attack Chain Explained
Prototype pollution is one of the most well-documented vulnerability classes in JavaScript. It occurs when an attacker can inject properties into the base Object.prototype, causing those properties to appear on every object created in the process.
Libraries like qs, minimist and body-parser ubiquitous in Node.js applications have all had prototype pollution vulnerabilities discovered in them over the years. Many applications are running versions that contain these flaws, often without knowing it.
CVE-2026-40175 does not directly exploit prototype pollution. Instead, it makes Axios a gadget a pre-existing mechanism that an attacker can use to transform an upstream prototype pollution vulnerability into something catastrophically more severe.
The attack flow works like this an attacker exploits prototype pollution in any other dependency in your stack to inject a property such as x-amz-target into the JavaScript prototype. When Axios subsequently builds an outbound HTTP request and it merges configuration objects in a way that picks up these tainted prototype properties and includes them as request headers.
Because Axios performs no validation or sanitization on header values and specifically it does not check for carriage return or line feed characters (CRLF) a maliciously crafted header value can smuggle an entirely separate HTTP request inside the socket write. This technique is known as HTTP request smuggling and allows the attacker to craft a secondary request targeting AWS EC2 Instance Metadata Service at the internal address 169.254.169.254.
The Proof of Concept released publicly on April 13, 2026 demonstrates this full chain end-to-end. A developer makes what looks from the source code like an entirely safe, hardcoded request to an external API.
There is nothing wrong with the developers code. There is nothing wrong with the Axios call itself in isolation. The attack is invisible until the moment the cloud credentials land on the attackers server. This is what makes it particularly insidious and traditional code review would not catch it and the blame does not fall on any single line in any single file.
Who Is Affected and What Needs to Happen
The scope of affected systems is broad by almost any measure. Every Axios version prior to 1.13.2 is explicitly vulnerable to the gadget attack chain. The formally patched version is 1.15.0, which enforces strict validation on all header values before passing them to the underlying request functions if any header value contains CRLF characters the library now immediately throws a security error and halts the request.
This seems like a simple fix and it is which makes the years of exposure all the more striking. Carriage return and line feed characters have no legitimate place in HTTP header values. The fact that they were never checked is not a sophisticated architectural failure it is a maintenance blind spot in a library that was trusted so deeply that people stopped questioning its internals.
Affected Versions
All Axios releases before version 1.13.2 are vulnerable to CVE-2026-40175. Organizations running any version in the 0.x branch, the 1.0 through 1.12 range, or any version below 1.13.2 are exposed. The minimum safe version is 1.15.0 which includes the complete fix. Two public Proof of Concept exploits are now available on GitHub, making exploitation accessible to any attacker with moderate technical competence.
Updating to 1.15.0 is the immediate action every team should take. But the response should not stop at a version bump. Organizations running Node.js applications need to audit the full dependency tree for prototype pollution vulnerabilities in libraries like qs, minimist and body-parser since those are the upstream entry points that make CVE-2026-40175 exploitable in practice.
Without a prototype pollution vector, the Axios gadget chain cannot be activated but relying on the absence of a second vulnerability as your primary defense is a fragile posture. The right answer is to fix both layers like patch Axios and remediate prototype pollution exposure in adjacent dependencies.
For teams that genuinely cannot update immediately, the security community has shared a manual mitigation that involves adding CRLF validation directly in the adapter code. By checking whether any header value matches the regex /[\r\n]/ and throwing an error if it does teams can neutralize the injection chain without changing the library version. This is a stopgap, not a solution but it is a meaningful reduction in risk for teams facing deployment constraints.
The Reality of Open Source Trust
Taken together, these two incidents tell a story that goes beyond Axios. The supply chain attack demonstrated that the security of a library used by 100 million developers every week can hinge on the account security practices of a single individual.
There is nothing in the npm publishing infrastructure that prevented a stolen token from being used to push malicious code to the world’s most trusted packages. The OIDC Trusted Publisher mechanism existed and was in use for Axios but it was optional, and its absence on the malicious publish was only detectable by a forensic comparison of metadata that no developer would check routinely.
CVE-2026-40175 meanwhile demonstrates the vulnerability pattern that security researchers call gadget chains a class of attack that has been well understood in the academic community for years but has rarely made headlines because it requires chaining two separate flaws together.
The rise of complex dependency trees in modern JavaScript applications means that the number of viable gadget chains increases with every package added to a project. An application with three hundred transitive dependencies has three hundred potential gadget entry points and each of which could potentially interact with a flaw in a trusted, widely used library in ways that create catastrophic outcomes no individual developer could have anticipated.
These are not the last incidents of this kind. The economic and geopolitical incentives for targeting open-source infrastructure — particularly the JavaScript ecosystem — are stronger now than they have ever been. SANS Institute, Emergency Briefing, April 1, 2026
The response from the security community has been fast and technically thorough. Elastic Security Labs, StepSecurity Microsoft Threat Intelligence, Trend Micro, and SANS all published detailed analyses within hours of the supply chain compromise being discovered.
The CVE disclosure process for the RCE vulnerability followed a responsible timeline. npm removed the malicious packages. GitHub issued advisories. The infrastructure worked more or lessand the way it was supposed to. And yet the exposure happened. The malware executed on real machines. The vulnerability was real and has public exploits.
The uncomfortable conclusion that both incidents force developers to confront is that supply chain security and dependency hygiene are not optional extras they are as foundational to application security as input validation or authentication.
Pinning exact dependency versions rather than using caret ranges. Verifying SLSA provenance attestations on package installs. Running npm ci --ignore-scripts in CI/CD pipelines to prevent postinstall hooks from executing. Monitoring network egress from build environments for unexpected outbound connections.
Auditing dependency trees regularly for known prototype pollution vulnerabilities. These are all known best practices. They were all known before March 2026. The gap between knowing them and actually doing them is exactly the gap that attackers exploit.
Final Thoughts on Axios
It would be unfair to end without saying this clearly: Axios is still a good library. The supply chain attack was not a failure of the librarys code and it was a failure of account security at the human level, and it was detected and contained within hours by an ecosystem that mobilized quickly.
CVE-2026-40175 is a real and serious vulnerability, but it has a fix available and the maintainers moved to address it. The appropriate response is not to abandon Axios but to update it and harden the surrounding environment and recognize that the same scrutiny we apply to our own code needs to be extended to the dependencies we trust without question.
The library that made HTTP requests simple for a generation of developers is still standing. The question is whether the developers who rely on it and will take the security of their toolchain as a seriously as they take the functionality of their features.