Axios npm Vulnerabilities: The Full CVE History and Patch Guide

The safest position on any axios npm vulnerability is to run a recent 1.x release (1.8.2 or later) and keep the transitive follow-redirects dependency current, because axios's real-world CVE history is split between flaws in axios itself and flaws in the redirect library it pulls in. Axios is one of the most downloaded packages on npm, which means its bugs land in a huge number of applications and its patches are worth applying promptly. Below is the CVE history in order, with the version that fixes each and the practical upgrade path.

Why does an axios npm vulnerability matter so much?

Axios ships in a very large share of JavaScript projects, front-end and back-end. Popularity is the reason a single CVE has outsized blast radius: one advisory can obligate thousands of teams to patch, and attackers know exactly which package to probe. It is also frequently a transitive dependency, pulled in by some other library, so teams get exposed to an axios npm vulnerability without ever adding axios to their own package.json. That is the pattern to watch.

What are the notable axios CVEs, in order?

Here is the history that actually matters for patching, oldest first.

A closer look at the two that most often surprise people:

• CVE-2023-45857 is a token-leakage issue. Vulnerable versions attach the secret XSRF-TOKEN cookie value as an X-XSRF-TOKEN header on requests to any host, not just your own API, so a request to a third-party endpoint could hand over the anti-CSRF token. If you use axios with cookie-based XSRF protection, this one applies to you. Fixed in 1.6.0.
• CVE-2025-27152 is an SSRF and credential-leakage flaw. When a baseURL is set but a request is made with an absolute URL, axios follows the absolute URL instead of staying within the base, which can send requests (and any attached credentials) to an attacker-controlled host. Fixed in 1.8.0 and further hardened in 1.8.2.

What about the transitive follow-redirects vulnerabilities?

This is the part teams miss. Axios depends on follow-redirects to handle HTTP redirects, and that library has had its own serious CVEs that reach you through axios:

• CVE-2023-26159 in follow-redirects is an improper URL-handling flaw fixed in 1.15.4.
• CVE-2024-28849 leaks the Proxy-Authorization header on cross-origin redirects, fixed in 1.15.6.

An old axios can resolve to a vulnerable follow-redirects even if the axios version itself has no open advisory. This is exactly why a manifest-only view is misleading: your package.json says axios, but your risk lives one level down in the resolved tree. Software composition analysis that reads the lockfile, not just the manifest, is what surfaces these. Safeguard's SCA resolves the full dependency graph so a transitive follow-redirects flaw shows up attributed to the path that introduced it.

How do you patch an axios npm vulnerability correctly?

A reliable patch workflow for axios, in order:

1. Find the resolved version, not the declared one. Run npm ls axios and npm ls follow-redirects to see every version actually in the tree, including duplicates pulled in by different dependents.
2. Upgrade axios to at least 1.8.2. That clears the axios-side CVEs above. If you are stuck on 0.x for legacy reasons, 0.21.2 is the minimum that addresses the early DoS/SSRF/ReDoS trio, but 0.x is unmaintained and you should plan the move to 1.x.
3. Force a current follow-redirects. Ensure follow-redirects resolves to 1.15.6 or later. If a transitive dependent pins an old one, use an npm overrides entry to force the safe version across the tree.
4. Regenerate and commit the lockfile. Run npm install, verify with npm ls again, and commit package-lock.json so the fix is reproducible in CI.
5. Re-scan. Confirm the advisories are gone from your composition scan, not just from your memory of what you upgraded.

An overrides block is the tool for the transitive case. It lets you pin follow-redirects to a patched version even when the intermediate package has not updated its own dependency range yet.

How do you stop the next one before it ships?

The axios story is the supply-chain story in miniature: a hugely popular package, recurring CVEs, and a transitive dependency with its own timeline. You cannot manually track every advisory across every dependency, so wire the check into the pipeline.

• Run SCA on every pull request against the resolved tree, and fail on new critical or high advisories in reachable code.
• Prefer reachability-aware scanning so you spend effort on the axios calls you actually make, not on theoretical paths.
• Keep lockfiles committed and renovate dependencies on a cadence rather than in a panic after an advisory drops.

For teams weighing options, our comparison with Snyk covers how transitive resolution and reachability differ between scanners, and the Safeguard blog tracks new npm supply-chain incidents as they land.

FAQ

What is the latest safe version of axios?

As of this writing, run 1.8.2 or later. That clears the known axios-side advisories including the 2025 absolute-URL SSRF (CVE-2025-27152). Always check your scanner for advisories published after your upgrade, since the package continues to evolve.

Do I have axios even if I did not install it?

Very possibly. Axios is a common transitive dependency, so another library may pull it in. Run npm ls axios to see whether it is in your resolved tree and which version and dependent introduced it.

Why does my scanner flag follow-redirects when I only use axios?

Because axios depends on follow-redirects, and that library has its own CVEs (CVE-2023-26159, CVE-2024-28849). A lockfile-aware scanner attributes the transitive flaw to the axios path that introduced it. Upgrading axios usually pulls a fixed version; if not, use an npm overrides entry.

Is the 0.x line of axios still safe to use?

No. The 0.x line is unmaintained. 0.21.2 addresses the earliest DoS, SSRF, and ReDoS CVEs, but later flaws are only fixed in 1.x. Plan a migration to a current 1.x release rather than pinning an old 0.x version.