Axios Security Guide (2026)

Axios is the most widely used standalone HTTP client in the JavaScript ecosystem. It works in both Node.js and the browser, wraps requests in a clean promise-based API with interceptors and automatic JSON handling, and shows up in a large share of front-end apps and Node backends alike. On npm it sees tens of millions of weekly downloads and is a dependency of a great many other packages. Because axios is the component that carries tokens, cookies, and credentials out to other servers — and often fetches URLs that originate from user input — its security history centers on SSRF and credential leakage, and those bugs are worth understanding before you ship.

The notable historical CVEs

Axios has a real, recurring set of published advisories around request handling:

• CVE-2020-28168 — a server-side request forgery issue where axios did not correctly honor proxy configuration on redirects, allowing a request to reach an unintended host. Fixed in 0.21.1.
• CVE-2021-3749 — a regular-expression denial of service (ReDoS) in the trim handling of response data. Fixed in 0.21.2.
• CVE-2023-45857 — axios versions before 1.6.0 would include the XSRF-TOKEN cookie value in the X-XSRF-TOKEN header on requests to any host, leaking the CSRF token to third parties. Fixed in 1.6.0.
• CVE-2024-28849 — in follow-redirects, a core axios dependency, the Authorization and Proxy-Authorization headers could be leaked across a cross-origin redirect. Fixed in follow-redirects 1.15.6.
• CVE-2025-27152 — an SSRF and credential-leakage issue where passing an absolute URL to a request would bypass a configured baseURL, allowing the request (and any attached credentials) to be sent to an attacker-controlled host. Fixed in axios 1.8.0.

The recurring theme mirrors other HTTP clients: requests going somewhere the developer did not intend (SSRF), and secrets riding along to hosts they should never reach.

Common misuse and risks

• Fetching user-controlled URLs. axios.get(req.query.url) is a textbook SSRF. Axios will fetch internal addresses and cloud metadata endpoints just as happily as external ones.
• Assuming baseURL sandboxes requests. As CVE-2025-27152 showed, an absolute URL can override baseURL entirely — so baseURL is not a security boundary.
• Attaching credentials globally. Setting an Authorization header on a shared instance and then following redirects can leak that credential across hosts.
• Disabling TLS verification. In Node, setting httpsAgent with rejectUnauthorized: false to silence certificate errors turns HTTPS into an unauthenticated channel.
• Running an old pinned version. Because axios is heavily transitive, a stale 0.x copy carrying the SSRF and ReDoS bugs can hide deep in a lockfile.

How to use axios safely

Set the version floor: run axios 1.8.2 or later (a current 1.x release), which carries the SSRF/baseURL-bypass fix, the XSRF-token leak fix, and pulls in a patched follow-redirects. Add a lockfile override if a transitive dependency drags in an older axios.

Then configure defensively:

• Always set an explicit timeout so a stalled server cannot hang your process.
• Validate any URL derived from user input: check the scheme and host against an allowlist and block private/link-local address ranges before calling out, to prevent SSRF. Do not rely on baseURL for this.
• Attach credentials per-request to the specific host that needs them, rather than globally on a shared instance, and be deliberate about redirect following (maxRedirects) on authenticated calls.
• Never disable certificate verification in production. Point axios at a proper CA bundle if you use a private authority.
• Cap response size with maxContentLength/maxBodyLength to limit memory-exhaustion risk.

How to monitor axios with SCA and reachability

Axios is present in nearly every JavaScript dependency tree, so version-based scanners flag it constantly. What determines real risk is narrower: are you on a patched version, and does your code actually reach the risky behavior — passing user input into a request URL, or attaching credentials to requests that follow redirects?

Safeguard's software composition analysis resolves your full lockfile — including the transitive axios and follow-redirects you did not choose directly — and adds call-path reachability, so an SSRF or credential-leak CVE that your code can actually trigger is separated from a dormant copy. When a patched release exists, autonomous auto-fix opens a tested pull request that bumps axios (or the transitive dependency) to the safe version. If you are comparing tools, the Safeguard vs Snyk breakdown covers the differences, and developers run the same analysis locally with the Safeguard CLI.

Bring continuous, prioritized dependency analysis to your JavaScript services — get started free or read the documentation.

Frequently Asked Questions

Which axios version is safe in 2026?

Run axios 1.8.2 or later on the 1.x line. That release includes the fix for the SSRF/baseURL-bypass issue (CVE-2025-27152), builds on the 1.6.0 fix for the XSRF-token leak (CVE-2023-45857), and pulls in a patched follow-redirects. Anything on the 0.x line is missing multiple fixes and should be upgraded.

Does axios protect me from SSRF?

No. Axios will fetch whatever URL you give it, including internal and cloud-metadata addresses, and an absolute URL can even override a configured baseURL. If any part of the request URL comes from user input, you must validate the scheme and host and block private address ranges yourself before making the call.

Is baseURL a security boundary in axios?

No. baseURL is a convenience for building relative request paths, not a sandbox. As CVE-2025-27152 demonstrated, passing an absolute URL bypasses it entirely. Never treat baseURL as a way to confine where requests can go.

Why did axios leak credentials on redirects?

Two mechanisms have appeared historically: the XSRF-TOKEN cookie being sent as a header to any host (CVE-2023-45857), and the Authorization/Proxy-Authorization headers leaking across a cross-origin redirect through follow-redirects (CVE-2024-28849). Both are fixed in current versions; the durable defense is scoping credentials per-host and being deliberate about redirect following.

How do I know if an axios CVE actually affects my app?

Use reachability-aware SCA. It traces whether your code reaches the vulnerable behavior — for example passing untrusted input into a request URL, or attaching credentials to requests that follow redirects — so you can prioritize the CVEs that are genuinely exploitable in your codebase.