axios Flaws Let Attackers Steal Credentials via Proxy SSRF and Prototype-Pollution MITM — Update to 1.16.0 Now (CVE-2026-44492 / CVE-2026-44494)

Two vulnerabilities that can leak credentials have been found and patched in axios, the HTTP client that apps around the world use to talk to other servers. axios is a "communication library" that lets programs in the browser or on a server exchange data with outside services, and it is downloaded more than 100 million times a week from npm (the package registry). Even if you never added it yourself, there is a good chance one of your apps or third-party services pulls it in under the hood.

There are two issues. One, CVE-2026-44492, slips past the setting (NO_PROXY) meant to block requests to internal servers and cloud management endpoints, letting an attacker steer a request there. The other, CVE-2026-44494, can quietly reroute every request your app makes through an attacker's server. Both are fixed in axios 1.16.0 (and 0.32.0 for the older line); the current latest is 1.17.0.

The flaws themselves were disclosed on May 29, 2026, but the international severity scores that made them widely visible were registered across databases only in June. There are no reports of exploitation in the wild so far, but because the number of apps that bundle axios is enormous, the safe move is to check your dependency tree and update now.

What axios is, and why it touches almost everyone

axios is a component that lets JavaScript programs (the language that runs the web and many servers) fetch and send data to other servers. Most of what we call "calling an API" or "integrating with an external service" runs on top of a communication library like this, and axios is the most widely used one in that space, with over 100 million downloads a week.

The tricky part is that even if your own app does not use axios directly, another component you depend on very often calls it internally. This is called a "transitive dependency." So even if you think "we don't use axios," it is common to find it buried deep in the dependency tree. As the table below shows, the starting point is to check how this relates to your own situation.

Of the two, the more directly dangerous case is running it on the server side (Node.js). In particular, services using axios on clouds such as AWS or Google Cloud should treat this as a priority, because it can lead to the cloud credential leak described below.

An overview of the two flaws

Both are holes in how axios handles a "proxy" (a server that relays traffic). Because their nature and the conditions needed to exploit them differ, let's first line up the differences. The severity numbers use "CVSS," the international common score that rates seriousness from 0 to 10.

In plain terms, CVE-2026-44492 is "a gap in the defensive wall," while CVE-2026-44494 is the "worst-case-if-it-lands, but only works paired with another hole" type. We cover that "precondition" for the latter, along with how to read the numbers, in a later section.

Who wants this bug, and what they walk off with

axios is the most widely used communication component in the world, and nearly all of the data an app handles passes through it. The people who want this are ransomware crews hunting a way into cloud environments, industrial spies poking at internal APIs, and access brokers who resell stolen credentials on underground markets. What they carry off are temporary AWS or Google Cloud credentials, internal-API access tokens, login IDs and passwords, cookies, and the customer personal data riding inside the requests. The moment the NO_PROXY block setting is slipped past, a credential sitting on a cloud's management server is delivered straight into their hands over a path that should never have led outside.

Pull one key, and with that privilege storage buckets are read in full, databases are peeked into, and the attack moves laterally to the next server. The stolen credentials are resold on underground markets, and the group that buys them plants ransomware — a two-stage routine that is now standard. If the prototype pollution flaw is struck instead, it is even more direct: every request the app sends routes through the attacker's server, IDs and passwords are logged verbatim on each login, and the responses are swapped out without anyone noticing. Nothing looks different to the user.

And the final responsibility falls not on the authors of axios, but on the company running the service that embedded it. If customer data leaks, reporting to the data protection authority and notifying affected individuals become obligations, and depending on scale, damages and lost trust weigh heavily. None of those after-the-fact costs are captured in a mid-8 CVSS number. With a fix already out, whether you can check one line of your dependencies and update is what decides which side of that line you land on.

A closer look at each hole

CVE-2026-44492: an SSRF that slips past the block setting to reach cloud keys

A server-side program blocks requests to "destinations that must not leave the box" — internal servers, cloud management endpoints — using a setting called NO_PROXY. axios has a routine named shouldBypassProxy that makes this decision, but it failed to correctly recognize a special way of writing addresses. That is CVE-2026-44492.

Concretely, IP addresses have two notations, "IPv4" and "IPv6," and an IPv4 address like 127.0.0.1 can point at the same destination written in IPv6 as ::ffff:7f00:1. Even if you put 127.0.0.1 in NO_PROXY to block it, when an attacker specifies the destination in the ::ffff:7f00:1 form, axios misjudges it as "not on the block list" and the request goes through. The most dangerous target is the metadata server (169.254.169.254) that returns cloud management info, where temporary credentials live. Struck with the rewritten form (::ffff:a9fe:a9fe), it can let cloud credentials be siphoned off. This is "SSRF (server-side request forgery)," the classic attack of tricking a server into making requests to internal destinations.

This hole actually remained because the fix for an earlier flaw, CVE-2025-62718 (the patch shipped in 1.15.0), was incomplete. That fix only anticipated the IPv4 spelling, leaving the IPv6 rewritten form as a backdoor. The difficulty of "normalization" — lining up notations so they can be compared — opened the same hole twice.

CVE-2026-44494: a prototype pollution that hijacks all traffic

The other flaw leads to a man-in-the-middle (MITM) attack whose impact, if it lands, is extreme. A man-in-the-middle attack is where an attacker wedges into the middle of communication to read and rewrite what passes through. The key is "prototype pollution," a weakness specific to JavaScript.

In JavaScript, every configuration object shares a "template (prototype)." If an attacker can write a proxy entry into that template, then when axios decides its own config has no proxy set, it picks up the value written into the template instead. Because axios traverses all the way to that template when reading the proxy setting, the attacker's server is slotted in as the proxy, and every later request routes through it. What is frightening is that the developer's code looks perfectly normal — just an ordinary axios.get(...) — yet the traffic is hijacked. In the reporter's proof of concept, a Basic-auth ID and password were recorded verbatim on the attacker's server.

There is, however, an important precondition. axios alone cannot trigger prototype pollution. The condition is that another library used by the same app has a prototype pollution flaw, and the template can be rewritten through it. Conversely, once that groundwork exists, axios automatically uses the polluted value even if the developer makes no mistakes at all — a chain called a "gadget." This "worst-case-with-a-precondition" nature is what makes the number hard to read.

Don't panic over the CVSS number alone

The reporter self-rated CVE-2026-44494 at "9.4 (critical)," and some databases assign a high score too. But this is where a cool head matters. As noted, this hole does not fire on its own; it only works when another library carrying a prototype pollution flaw lives alongside it. In other words, the score reflects "the worst case when every condition aligns," not that every axios environment is at the same risk right now.

This "number taking on a life of its own" has been debated around axios before. For a separate prototype-pollution flaw, ITmedia reported experts pointing out that despite a top score of 10, real exploitation requires strict conditions, and there is a gap between the score and the operational risk. CVSS is a ruler for "theoretical worst case," and the realistic risk in your environment cannot be judged without also checking whether your dependencies contain a pollution trigger and whether your code lets an external value shape the request destination.

The other flaw, CVE-2026-44492, has a lighter precondition and is more direct. If your code lets an attacker specify the request URL (for example, building the destination from a value received externally), that alone slips past the block setting. If you run axios in the cloud, treat this not as "if conditions align" but as "a backdoor that is here now." Rather than the size of the number, mapping each flaw onto your own design and its preconditions is the trick to fixing things calmly and surely.

Does your axios need updating (version cheat sheet)

You can check the version in use by running npm ls axios in your project folder. It lists which versions are installed, including transitive ones. Match your number in the table below. The fixed versions are 1.16.0 or later (latest is 1.17.0), or 0.32.0 if you are on the old 0.x line.

Where possible, it is safer to move off the old 0.x line and onto the latest of the current 1.x line. The 0.x line is thinly maintained and has accumulated multiple vulnerabilities over time. If an old axios is present via a transitive dependency, you may need to update the parent component that brings it in, so running npm ls axios first to see "which component is dragging in the old axios" makes the work easier to plan.

What to do right now

The surest fix is to update axios to 1.16.0 or later (ideally the latest, 1.17.0), or 0.32.0 on the old line. If you depend on it directly, npm install axios@latest bumps it. For transitive dependencies, confirm the match with npm audit or a vulnerability database, then either update the parent component or force a safe version with npm's overrides feature.

If you cannot update immediately, practical stopgaps include not using externally received values directly as the request URL, also blocking access to the cloud metadata server by another mechanism (IMDSv2 or network-level restrictions), and checking your dependencies for known prototype pollution holes. But these only buy time; the root fix is updating the library itself. No real-world attacks have been confirmed so far, but the location of a flaw becomes easier to map once a fix ships, so delay is simply accumulated risk.

Why axios keeps having vulnerabilities

Since the start of 2026, axios has seen a run of vulnerabilities around proxies and prototype pollution. These two are part of a series of "gadget-type" holes that researchers found while carefully auditing the source. Behind it lies a structural fact: JavaScript's prototype mechanism, in exchange for its convenience, makes it easy to create paths through which unexpected values slip in. Proxy handling is likewise hard to get fully right because of subtle differences in IP-address notation, so a backdoor often remains even after a fix.

On top of that, axios was the target of a supply-chain attack in March 2026, when a maintainer's account was hijacked and malicious versions were briefly published. A staple component with an outsized user base is exactly that much more lucrative to attackers, and it stays targeted from both sides — flaws in the code itself, and attacks on the distribution path. npm's move to stop dependency packages from auto-running install scripts is of a piece with this trend.

That is exactly why it pays to continuously check which versions your imported components are, and whether they carry known holes. Running your dependency list through an OSS vulnerability check that flags dangerous versions from a pasted dependency list helps you catch "an old axios lurking deep down" early. The more standard a component is, the easier its updates are to put off — but never forget that the sheer number of places it is used translates directly into the breadth of the damage.

Sources

• ▸ axios advisory - GHSA-pjwm-pj3p-43mv (CVE-2026-44492 / NO_PROXY bypass)
• ▸ axios advisory - GHSA-35jp-ww65-95wh (CVE-2026-44494 / prototype pollution MITM)
• ▸ NVD - CVE-2026-44492
• ▸ NVD - CVE-2026-44494
• ▸ axios - release notes (v1.16.0)
• ▸ ITmedia - Warning against a 10/10 score "taking on a life of its own" (prior axios case, Japanese)
• ▸ npm - axios package page