Safeguard
Security

CVE-2023-45857: The Axios XSRF Token Leak Explained

How CVE-2023-45857 caused Axios to leak XSRF tokens to any host over cross-origin requests, who is affected, and the one-line upgrade that fixes it.

Aisha Rahman
Security Analyst
6 min read

CVE-2023-45857 is an information-disclosure vulnerability in the Axios HTTP client that causes it to send your XSRF-TOKEN cookie value in the X-XSRF-TOKEN header to every host, including cross-origin destinations, whenever withCredentials is enabled. It affects Axios versions from 0.8.1 through 1.5.1 and carries a CVSS v3 base score of 7.1 (High). The fix is a straightforward upgrade to Axios 1.6.0 or later. If you run a JavaScript or Node.js application that uses Axios with credentialed requests, this is one worth understanding, because the leaked token can enable cross-site request forgery against your users.

What the flaw actually does

Axios has a built-in convenience feature for CSRF protection: when it detects an XSRF-TOKEN cookie, it automatically copies that value into an X-XSRF-TOKEN request header. The intent is that your backend reads the header, compares it to the cookie, and rejects any request where they don't match — the classic double-submit cookie pattern.

The bug in CVE-2023-45857 is that Axios attached this header to every request when withCredentials: true was set, regardless of the destination host. So if your app talked to api.yoursite.com and also, for any reason, made a request to attacker.example, the victim's XSRF token traveled along in the header to the attacker's server.

That token is supposed to be a secret shared only between the browser and your origin. Once an attacker holds a valid token, they can craft forged requests that pass your CSRF check, because from the server's perspective the token is legitimate.

Who is affected

You are exposed if all of the following are true:

  • Your application depends on Axios between version 0.8.1 and 1.5.1.
  • You make requests with withCredentials: true (or a global axios.defaults.withCredentials = true).
  • Your app can be induced to send a request to a host you don't control — through a user-supplied URL, an SSRF-adjacent proxy pattern, a misconfigured base URL, or an open redirect that Axios follows.

The most common real-world trigger is an application that sets withCredentials globally and then makes requests to third-party APIs or user-influenced endpoints. If you only ever call your own same-origin backend and never enable credentialed cross-origin requests, your practical exposure is lower, but you should still upgrade, because "we never call other hosts" tends to stop being true as codebases grow.

The CVSS score and what it means

The vector for CVE-2023-45857 is CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N, giving a base score of 7.1. Breaking that down: the attack is exploitable over the network with low complexity and no privileges, but it requires user interaction (the victim has to trigger the vulnerable request), the confidentiality impact is High (the token leaks), and integrity impact is Low. There is no availability impact.

A High rating here is appropriate. The token leak is not an immediate RCE, but it undermines a control — CSRF protection — that many teams assume is airtight, and it does so silently.

How to fix CVE-2023-45857

The remediation is to upgrade Axios to 1.6.0 or newer, where the header is only attached to same-origin requests as intended.

npm install axios@^1.6.0
# or
yarn add axios@^1.6.0

After upgrading, run npm ls axios to confirm no transitive dependency still pins an old version. Axios is a hugely popular transitive dependency, so it's common to have both a direct install at a safe version and an old copy dragged in by another package. If a dependency pins a vulnerable range, use an override:

{
  "overrides": {
    "axios": "^1.6.0"
  }
}

If you genuinely cannot upgrade immediately, the interim mitigation from the advisory is to change the XSRF cookie name away from the default and set the corresponding header manually only on the requests that need it — but this is a stopgap, not a fix. Upgrading is far simpler and removes the risk entirely.

Finding it across your codebase

The hard part of a CVE like this is rarely the fix — it's knowing every place the vulnerable version lives. A single monorepo can carry a dozen copies of Axios across services, lockfiles, and vendored bundles. Manually grepping package-lock.json files does not scale, and it won't catch a version pinned four layers deep in a transitive tree.

This is exactly what software composition analysis is for. An SCA tool such as Safeguard can flag CVE-2023-45857 transitively — surfacing the specific projects and lockfiles carrying a vulnerable Axios even when nothing in your package.json names it directly. If you're evaluating tooling for this, our SCA product overview walks through how transitive detection works, and the Academy has a primer on triaging findings by real-world reachability rather than raw CVE count.

Lessons beyond this one CVE

CVE-2023-45857 is a tidy example of a broader pattern: a "helpful" default that leaks data across a trust boundary. The Axios team added automatic CSRF header injection to make developers' lives easier, and the flaw was simply that the boundary check — same origin only — was missing. This is the same failure mode behind many credential-leak CVEs across HTTP libraries.

Two habits blunt this class of bug. First, be explicit about withCredentials per request instead of setting it globally; a global default means every future request inherits credential-sending behavior the original author never reviewed. Second, keep your HTTP client patched aggressively — Axios ships security fixes regularly, and staying within one minor version of current turns most of these advisories into a no-op upgrade you've already done.

FAQ

What versions of Axios are vulnerable to CVE-2023-45857?

Axios versions 0.8.1 through 1.5.1 are affected. The vulnerability was fixed in Axios 1.6.0, so any version at or above 1.6.0 is safe.

Is CVE-2023-45857 exploitable if I don't use withCredentials?

The leak is triggered specifically by credentialed requests, so applications that never enable withCredentials have much lower practical exposure. However, because the setting is often applied globally and codebases evolve, upgrading is still the recommended action rather than relying on that condition holding.

What is the CVSS score of CVE-2023-45857?

It has a CVSS v3 base score of 7.1, rated High, driven mainly by the High confidentiality impact of leaking a secret CSRF token to an untrusted host.

How do I know if a transitive dependency pulls in a vulnerable Axios?

Run npm ls axios to see the full dependency tree, or use a software composition analysis tool that maps transitive dependencies against vulnerability databases. If a dependency pins an old range, an overrides (npm) or resolutions (Yarn) entry forces a safe version.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.