npm install axios: A Security Review and Safe Usage Guide

When you run npm install axios you get a widely used, well-maintained HTTP client, but the version it resolves to determines whether you are pulling in fixed code or a release with a known SSRF or credential-leak vulnerability. Axios is one of the most depended-on packages on npm, which makes it a frequent target for scrutiny — and it has shipped several real CVEs over the last few years. Installing it safely is less about the command and more about the version you pin and how you configure requests.

The command itself is trivial. npm install axios writes the latest release to your dependencies and updates the lockfile. But "latest" only helps if you actually run the install now; a project scaffolded two years ago and never updated is sitting on an old, vulnerable copy even though the newest release is clean.

What npm install axios actually resolves

By default npm install axios fetches the newest published version and records a caret range like ^1.7.0 in package.json. The caret allows future minor and patch updates within the same major, which is usually what you want for a library that ships security fixes as patch releases. If you want the exact version written with no range flexibility, use install axios npm with the --save-exact flag:

# resolves to whatever is newest today
npm install axios

# pin the exact version, no caret
npm install axios --save-exact

# check what actually got installed
npm ls axios

Always run npm ls axios afterward. In a real project axios often arrives twice — once as your direct dependency and once nested under something like a testing or SDK package — and the nested copy can be an old, vulnerable version even when your top-level pin is current.

The axios CVEs worth knowing

Axios has had a handful of confirmed vulnerabilities, and all of them are fixed in recent releases. These are verifiable in the GitHub Advisory Database and NVD:

• CVE-2023-45857 — a CSRF token was leaked because the XSRF-TOKEN cookie value was attached as a header on cross-origin requests. It affects axios 1.0.0 through 1.5.1 and is fixed in 1.6.0.
• CVE-2024-39338 — a server-side request forgery flaw where a path-relative URL could be treated as a protocol-relative URL, letting a request reach an unintended host. It affects 1.3.2 through 1.7.3 and is fixed in 1.7.4.
• CVE-2025-27152 — SSRF and possible credential leakage: with certain baseURL configurations, a request built from an absolute URL could resolve to a different host than intended and carry auth headers along with it. It is fixed in 1.8.0.

The pattern across these is consistent: the danger is not axios executing malicious code, it is axios sending your request — and its headers — somewhere you did not intend. That is why SSRF keeps recurring for HTTP clients. If you are on a modern release the fixes are in place, but a tool like software composition analysis will still flag a stale transitive copy hiding several layers down that your top-level pin never touched.

Configuring axios so it does not leak credentials

Most of the axios CVEs share a root cause you can defend against regardless of version: uncontrolled URL resolution and blanket header attachment. Two habits shrink the blast radius.

First, do not attach secrets to a shared client instance if you make requests to more than one host. When you set an Authorization header on the default axios instance, it travels on every request that instance makes. Scope credentials to the specific request or to a dedicated instance bound to one base URL:

import axios from 'axios';

// dedicated instance, one trusted host, one credential scope
const api = axios.create({
  baseURL: 'https://api.internal.example.com',
  timeout: 5000,
});

api.interceptors.request.use((config) => {
  config.headers.Authorization = `Bearer ${getToken()}`;
  return config;
});

Second, never build a request URL from untrusted input without validating it. If a user-supplied value ends up in the URL, an attacker can steer the request toward internal metadata endpoints or other hosts. Validate against an allowlist of expected hosts before the call goes out. This is the same class of defense that would have blunted the SSRF CVEs above.

Keeping the install healthy over time

A one-time clean install decays. Add npm audit to your pipeline and treat a failing audit as a build failure for high-severity findings:

npm audit --audit-level=high

npm audit reads your lockfile against the advisory database and reports known-vulnerable versions, including the nested copies npm ls reveals. Pair it with a bot such as Dependabot or Renovate so patch releases like 1.6.0 or 1.7.4 land automatically instead of waiting for someone to remember. For a broader look at scanning npm dependencies, the SCA product page walks through catching these transitively.

FAQ

Is npm install axios safe to run right now?

Yes. The current published axios is clean, and npm install axios will fetch it. The risk is not the install command, it is running on an old version pinned long ago — check with npm ls axios and update if you are behind.

Which axios version should I pin to?

Pin to a release at or above the newest fix relevant to you. 1.8.0 and later carry the fixes for the CSRF token leak, the path-relative SSRF, and the absolute-URL SSRF. Staying on the latest patch of the current major is the safest default.

Does npm audit catch axios vulnerabilities?

Yes. npm audit cross-references your lockfile against the advisory database and reports vulnerable axios versions, including nested transitive copies. Run it in CI with --audit-level=high so a known-vulnerable axios fails the build.

How do I stop axios from leaking my auth token?

Do not set credentials on a shared client used for multiple hosts, and validate any user-influenced URL against a host allowlist before making the request. Both practices counter the SSRF and credential-leak patterns behind the axios CVEs.