Summary
Axios: NO_PROXY bypass for 0.0.0.0 local addresses in axios
Axios versions containing lib/helpers/shouldBypassProxy.js do not treat 0.0.0.0 as a local address when evaluating NO_PROXY rules. In Node.js applications that use HTTP_PROXY or HTTPS_PROXY together with NO_PROXY=localhost,127.0.0.1,::1 or similar, a request to http://0.0.0.0:<port>/ can be routed through the configured proxy instead of bypassing it.
The issue is exploitable when an attacker can influence the axios request URL or a followed redirect target, and when the proxy can reach or relay 0.0.0.0 to local services. This is a Node.js runtime proxy-routing issue, not a browser, install-time, or development-tooling issue.
Affected Functionality
Affected functionality is limited to environment-derived proxy selection in the Node HTTP adapter:
lib/adapters/http.jscallsgetProxyForUrl(location)and thenshouldBypassProxy(location)before applying the proxy.lib/helpers/shouldBypassProxy.jsnormalizes and comparesNO_PROXYentries.- Explicit caller-provided
config.proxyremains trusted caller configuration. - Browser, React Native, XHR, and fetch adapter behavior are not affected.
Technical Details
lib/helpers/shouldBypassProxy.js defines local loopback equivalence through isLoopback(). The current implementation recognizes localhost, IPv4 127.0.0.0/8, IPv6 ::1, and IPv4-mapped loopback forms, but it does not include 0.0.0.0.
At lib/helpers/shouldBypassProxy.js:176, axios treats two hosts as matching when both are considered loopback:
return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));
Because isLoopback('0.0.0.0') returns false, NO_PROXY=localhost,127.0.0.1,::1 does not match http://0.0.0.0:<port>/. lib/adapters/http.js:185-193 then applies the environment proxy.
Proof of Concept of Attack
import http from 'http';
import axios from './index.js';
const listen = (handler, host = '127.0.0.1') =>
new Promise((resolve) => {
const server = http.createServer(handler);
server.listen(0, host, () => resolve(server));
});
const close = (server) => new Promise((resolve) => server.close(resolve));
const origin = await listen((req, res) => res.end('origin'), '0.0.0.0');
let proxyRequests = 0;
const proxy = await listen((req, res) => {
proxyRequests += 1;
res.end('proxied');
});
process.env.http_proxy = `http://127.0.0.1:${proxy.address().port}`;
process.env.HTTP_PROXY = process.env.http_proxy;
process.env.no_proxy = 'localhost,127.0.0.1,::1';
process.env.NO_PROXY = process.env.no_proxy;
try {
const direct = await axios.get(`http://127.0.0.1:${origin.address().port}/`);
const zero = await axios.get(`http://0.0.0.0:${origin.address().port}/`);
console.log({ direct: direct.data, zero: zero.data, proxyRequests });
} finally {
await close(origin);
await close(proxy);
}
Expected safe behavior: both 127.0.0.1 and 0.0.0.0 bypass the proxy when the NO_PROXY policy is intended to cover local destinations.
Observed behavior: 127.0.0.1 bypasses the proxy, while 0.0.0.0 is sent through the proxy.
Workarounds
- Add
0.0.0.0explicitly toNO_PROXYwhere local addresses must bypass proxies. - Reject or normalize
0.0.0.0in application URL validation before calling axios. - Set
proxy: falseon axios requests that must never use environment proxies. - Configure the proxy itself to reject
0.0.0.0, loopback, link-local, and internal address ranges.
axios versions 1.15.0–1.16.1 contain an incomplete loopback-address check in lib/helpers/shouldBypassProxy.js. The isLoopback() function correctly identifies 127.0.0.0/8 and ::1 as loopback addresses but does not recognise 0.0.0.0, the IPv4 unspecified address, which routes to the local machine on Linux and macOS.
An attacker who controls a URL passed to axios can use http://0.0.0.0/<path> to bypass proxy-based SSRF filtering that the application relies upon.
Details
Affected versions
>= 1.15.0, <= 1.16.1
The vulnerability was introduced in v1.15.0 when the shouldBypassProxy helper was added as a security improvement (PR #10661).
Root cause
File: lib/helpers/shouldBypassProxy.js
// Line 1, static allowlist (incomplete)
const LOOPBACK_HOSTNAMES = new Set(['localhost']); // ← 0.0.0.0 missing
const isIPv4Loopback = (host) => {
const parts = host.split('.');
if (parts.length !== 4) return false;
if (parts[0] !== '127') return false; // ← 0.0.0.0: parts[0] = '0' → false
return parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255);
};
const isLoopback = (host) => {
if (!host) return false;
if (LOOPBACK_HOSTNAMES.has(host)) return true; // ← '0.0.0.0' not in set
if (isIPv4Loopback(host)) return true; // ← returns false for 0.0.0.0
return isIPv6Loopback(host);
};
isLoopback('0.0.0.0') returns false.
Node's WHATWG URL parser does not normalise 0.0.0.0 to 127.0.0.1. Other bypass forms are safe: new URL('http://0177.0.0.1/').hostname → '127.0.0.1' (octal), new URL('http://2130706433/').hostname → '127.0.0.1' (decimal), new URL('http://0x7f000001/').hostname → '127.0.0.1' (hex). Only 0.0.0.0 escapes normalisation.
### PoC
'use strict';
// Verbatim copy of relevant logic from axios v1.16.1 shouldBypassProxy.js
const LOOPBACK_HOSTNAMES = new Set(['localhost']);
const isIPv4Loopback = (host) => {
const parts = host.split('.');
if (parts.length !== 4) return false;
if (parts[0] !== '127') return false;
return parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255);
};
const isLoopback = (host) => {
if (!host) return false;
if (LOOPBACK_HOSTNAMES.has(host)) return true;
return isIPv4Loopback(host);
};
// 1. Show URL parser does NOT normalise 0.0.0.0
console.log(new URL('http://0.0.0.0/').hostname); // → '0.0.0.0' ← NOT normalised
console.log(new URL('http://0177.0.0.1/').hostname); // → '127.0.0.1' ← normalised (safe)
console.log(new URL('http://2130706433/').hostname); // → '127.0.0.1' ← normalised (safe)
// 2. Show isLoopback fails for 0.0.0.0
console.log(isLoopback('0.0.0.0')); // → false ← BUG: should be true
console.log(isLoopback('127.0.0.1')); // → true ← correct
Verified output on Node.js v22 / axios v1.16.1:
0.0.0.0 ← NOT normalised by URL parser
127.0.0.1 ← octal normalised correctly
127.0.0.1 ← decimal normalised correctly
false ← 0.0.0.0 not detected as loopback ⚠
true ← 127.0.0.1 correctly detected
### Impact
Applications that:
Accept user-supplied URLs and pass them to axios
Use a proxy with NO_PROXY=localhost (or similar) for SSRF filtering
…can be bypassed by supplying http://0.0.0.0/<path>. Axios routes the request through the proxy (shouldBypassProxy returns false). If the proxy itself does not filter 0.0.0.0, the connection reaches the local machine, exposing internal services such as cloud IMDS endpoints, internal admin panels, or microservice APIs.
Fix
Minimal (one line):
- const LOOPBACK_HOSTNAMES = new Set(['localhost']);
+ const LOOPBACK_HOSTNAMES = new Set(['localhost', '0.0.0.0']);
Comprehensive:
const isIPv4Unspecified = (host) => host === '0.0.0.0';
const isLoopback = (host) => {
if (!host) return false;
if (LOOPBACK_HOSTNAMES.has(host)) return true;
if (isIPv4Loopback(host)) return true;
if (isIPv4Unspecified(host)) return true; // add this line
return isIPv6Loopback(host);
};
</details>
Impact
Applications are affected when all of the following are true:
- The application runs axios in Node.js with the HTTP adapter.
- The process uses environment proxy variables such as
HTTP_PROXYorHTTPS_PROXY. - The process uses
NO_PROXYentries such aslocalhost,127.0.0.1, or::1to keep local traffic out of the proxy path. - Attacker-controlled input can influence the request URL or redirect target.
- The configured proxy does not reject
0.0.0.0and can reach the local destination.
For plain HTTP targets, the proxy can receive the full request URL, headers, and body, and may be able to observe the local service response. HTTPS targets are less exposed because axios uses CONNECT tunneling in current versions.
Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
axios to 1.18.0 or later; axios to 0.33.0 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-F4GW-2P7V-4548? GHSA-F4GW-2P7V-4548 is a medium-severity server-side request forgery (SSRF) vulnerability in axios (npm), affecting versions >= 1.15.0, < 1.18.0. It is fixed in 1.18.0, 0.33.0. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
- Which versions of axios are affected by GHSA-F4GW-2P7V-4548? axios (npm) versions >= 1.15.0, < 1.18.0 is affected.
- Is there a fix for GHSA-F4GW-2P7V-4548? Yes. GHSA-F4GW-2P7V-4548 is fixed in 1.18.0, 0.33.0. Upgrade to this version or later.
- Is GHSA-F4GW-2P7V-4548 exploitable, and should I be worried? Whether GHSA-F4GW-2P7V-4548 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-F4GW-2P7V-4548 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-F4GW-2P7V-4548?
- Upgrade
axiosto 1.18.0 or later - Upgrade
axiosto 0.33.0 or later
- Upgrade