Outdated Axios Library Leaks Security Tokens to Third-Party Servers

Vulnerability Explanation

Axios contained a logic flaw in its XHR adapter (`lib/adapters/xhr.js`) where the condition for attaching the `X-XSRF-TOKEN` request header was `(config.withCredentials || isURLSameOrigin(fullPath))`. Because this is a logical OR, enabling `withCredentials: true` caused the same-origin check to be short-circuited entirely. As a result, the `XSRF-TOKEN` cookie value was forwarded in the `X-XSRF-TOKEN` header on every outbound request — including cross-origin requests to third-party hosts — whenever `withCredentials` was set. An attacker controlling or monitoring a third-party endpoint that the application calls could harvest this token and use it to bypass CSRF protections on the victim's origin.

Root Cause

A boolean short-circuit in the XSRF token inclusion condition (`withCredentials || isURLSameOrigin`) caused the same-origin guard to be bypassed when `withCredentials` was enabled. The fix changes the condition so that the XSRF token is only attached when the request is same-origin (or when the new explicit `withXSRFToken` option is set to `true`).

Technical Impact

If exploited, an attacker who controls or can observe a cross-origin endpoint that the application calls (e.g., a third-party API, analytics service, or CDN) can obtain the victim user's XSRF token. With this token, the attacker can bypass CSRF protections and perform authenticated state-changing actions on behalf of the user — such as changing account settings, initiating transactions, or modifying data.

Severity Justification

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. Network-exploitable with low complexity, but requires user interaction and is only exploitable when both `withCredentials: true` is set AND the application makes cross-origin requests. EPSS is ~0.1%, indicating low observed exploitation in the wild.

Affected Components

• axios >= 0.8.1, < 0.28.0
• axios >= 1.0.0, < 1.6.0

Remediation Steps

1. Upgrade Axios to `0.28.0` (for 0.x projects) or `1.6.0` (for 1.x projects) or any later release: `npm install axios@latest` or pin to a specific safe version in `package.json`.
2. If you are on the 0.x branch and cannot upgrade to 0.28.0, apply the interim workaround: rename the default XSRF cookie name in your Axios config and manually attach the header only on same-origin requests (see code example below).
3. Search your codebase for transitive dependencies that bundle their own copy of Axios (e.g., older SDKs). Use `npm ls axios` or `npx audit` to surface all resolved versions.
4. After upgrading to 1.6.0+, note the new `withXSRFToken` option: XSRF tokens are no longer sent automatically on cross-origin requests even when `withCredentials` is true. If you intentionally need cross-origin XSRF token forwarding, set `withXSRFToken: true` explicitly.
5. Run your test suite after upgrading — the behavioural change may affect integration tests that assert on request headers.

Verification Steps

1. Run `npm ls axios` in your project root and confirm no resolved version falls in the range `>=0.8.1 <0.28.0` or `>=1.0.0 <1.6.0`.
2. Run `npm audit` and confirm CVE-2023-45857 / GHSA-wf5p-g6vw-rhxx no longer appears in the output.
3. In a browser devtools Network tab, make a cross-origin Axios request with `withCredentials: true` and verify that the `X-XSRF-TOKEN` header is NOT present on requests to third-party hosts.

Code Examples (javascript)

// Axios < 0.28.0 / < 1.6.0
// In xhr.js (internal), the condition was:
// if (config.withCredentials || isURLSameOrigin(fullPath)) {
//   requestHeaders['X-XSRF-TOKEN'] = cookies.read(config.xsrfCookieName);
// }
// Result: XSRF token sent to ALL hosts when withCredentials is true
const instance = axios.create({
  withCredentials: true, // ← triggers the bug
});
await instance.get('https://third-party-api.example.com/data');
// X-XSRF-TOKEN header is incorrectly included ↑

// Option 1: Upgrade to axios >= 0.28.0 or >= 1.6.0 (recommended)
// No code change needed — the library now only sends X-XSRF-TOKEN to same-origin requests by default.

// Option 2 (axios >= 1.6.0): Opt-in to cross-origin XSRF token forwarding explicitly
const instance = axios.create({
  withCredentials: true,
  withXSRFToken: true, // Only set this if you intentionally need cross-origin XSRF forwarding
});

// Option 3: Interim workaround for projects that cannot upgrade immediately
const instance = axios.create({
  xsrfCookieName: 'MY-APP-XSRF-TOKEN', // Rename to a non-default name
  xsrfHeaderName: 'X-MY-APP-XSRF-TOKEN',
});
// Then manually attach the header only in interceptors scoped to same-origin requests

Best Practices

• Pin and regularly audit third-party JavaScript dependencies using `npm audit` or a software composition analysis (SCA) tool integrated into your CI pipeline.
• Scope XSRF token forwarding explicitly: never rely on implicit library behaviour for security-sensitive headers — always configure token attachment to be opt-in per request or per Axios instance.
• When using `withCredentials: true`, ensure your CORS policy on the server side is as restrictive as possible (`Access-Control-Allow-Origin` should not be a wildcard).
• Use `npm ls <package>` to detect multiple resolved versions of the same library across your dependency tree, especially for security-sensitive packages.

References

• nvd.nist.gov/vuln/detail/CVE-2023-45857
• github.com/advisories/GHSA-wf5p-g6vw-rhxx
• github.com/axios/axios/issues/6006
• github.com/axios/axios/pull/6091
• github.com/axios/axios/releases/tag/v0.28.0
• github.com/axios/axios/releases/tag/v1.6.0
• security.snyk.io/vuln/SNYK-JS-AXIOS-6032459