CVE-2026-44487

What it actually does

Axios versions before 0.32.0 and before 1.16.0 can incorrectly forward a Proxy-Authorization HTTP header when running in Node.js and following certain redirects. The issue occurs when a request is initially sent through an authenticated HTTP proxy, Axios follows a redirect, and the redirected destination is reached directly rather than through the proxy. In that proxy-to-direct redirect flow, credentials intended only for the outbound proxy may be sent to the final origin server, exposing proxy authentication secrets to an unintended party. The vulnerability does not require code execution or authentication by the attacker, but exploitation depends on an affected application making Axios requests through an authenticated proxy and following attacker-influenced or attacker-observable redirects.

Why it matters to the business

Successful exploitation can leak proxy credentials to an external server, potentially allowing unauthorized use of corporate proxy infrastructure, bypass of network egress controls, traffic interception opportunities, or access to internal-only outbound paths depending on how the proxy account is configured. Because Axios is widely used in Node.js applications and libraries, the exposure may exist indirectly through downstream dependencies even where Axios is not used directly. The EPSS score is currently low and the issue is not listed in CISA KEV, but credential exposure flaws should still be prioritized where applications use authenticated HTTP proxies or process untrusted URLs.

How an attack unfolds

An attacker first needs a way to influence or receive an HTTP request made by a Node.js application using a vulnerable Axios version. The vulnerable application sends the request through an authenticated HTTP proxy, including a Proxy-Authorization header intended for that proxy. The attacker-controlled or attacker-influenced endpoint responds with a redirect to a destination that Axios reaches without using the proxy. During the affected redirect flow, Axios may fail to strip the proxy credential and sends the Proxy-Authorization header to the redirected origin. If the attacker controls or can observe that final origin, they can capture the proxy credential from HTTP access logs, application logs, packet captures, or request headers, then attempt to reuse it against the proxy or other systems where the same credential is valid.

How to fix it

Upgrade Axios to a fixed release: use axios 0.32.0 or later for the 0.x branch, or axios 1.16.0 or later for the 1.x branch. Where possible, upgrade to the latest stable 1.x release and regenerate lockfiles so transitive dependency resolution does not retain a vulnerable version. If immediate upgrade is not possible, mitigate by disabling automatic redirects for requests that use authenticated proxies, stripping Proxy-Authorization before following redirects, avoiding requests to untrusted URLs through authenticated proxies, and enforcing proxy credentials with least privilege, short lifetimes, and destination restrictions. Rotate any proxy credentials that may have been exposed through redirected Axios requests.

How to confirm the fix worked

Confirm all deployed Node.js applications and build artifacts resolve Axios to 0.32.0 or later on the 0.x line, or 1.16.0 or later on the 1.x line. Check package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container images, serverless bundles, and vendored node_modules directories for vulnerable Axios versions. Run dependency scanners such as npm audit, osv-scanner, Snyk, Dependabot, or equivalent software composition analysis tools. For behavioral validation, create a controlled test using an authenticated HTTP proxy and a redirect to a direct test endpoint, then verify the final endpoint does not receive any Proxy-Authorization header after the upgrade or mitigation.

Typical attack path

1. Identify a Node.js application or dependency that uses a vulnerable Axios version and follows redirects.
2. Find functionality where the application makes outbound HTTP requests using an authenticated HTTP proxy.
3. Influence the initial URL or upstream response so the request receives a redirect from a proxied request to a direct final origin.
4. Operate or observe the redirected origin server that receives the final request.
5. Capture the leaked Proxy-Authorization header from request logs or traffic.
6. Decode or reuse the exposed proxy credential, subject to the proxy authentication scheme and network reachability.
7. Use the credential to access proxy services, impersonate permitted outbound traffic, or support further reconnaissance.

How to detect it

Look for evidence that Proxy-Authorization headers were sent to non-proxy origin servers. Useful sources include application outbound request logs, HTTP reverse proxy logs, web server access logs on destinations receiving callbacks or fetched URLs, proxy authentication logs, WAF logs, API gateway logs, packet captures, and APM traces that record request headers. Search for requests where a normal origin service, webhook receiver, redirect target, or external HTTP endpoint received a Proxy-Authorization header. Correlate these events with Axios-based Node.js services, outbound requests that returned 3xx redirect responses, and subsequent direct requests to a different host. Also review proxy logs for unusual authentication attempts, new source addresses, abnormal destinations, high request volume, or activity after credential rotation. If exposed credentials used Basic authentication, treat the base64 value as compromised even if only partial logs are available.

• Proxy-Authorization:
• proxy-authorization:
• Proxy-Authorization: Basic
• Proxy-Authorization: Bearer
• Proxy-Authorization: NTLM
• Proxy-Authorization: Negotiate
• "proxy-authorization"
• "Proxy-Authorization"
• axios/
• HTTP 301
• HTTP 302
• HTTP 303
• HTTP 307
• HTTP 308

What your security team should do

• Inventory Node.js services and libraries that use Axios, including transitive dependencies and packaged runtime artifacts.
• Prioritize remediation for applications that use authenticated HTTP proxies, perform server-side URL fetching, follow redirects, or consume URLs controlled by users or third parties.
• Upgrade Axios to 0.32.0 or later, or 1.16.0 or later, and rebuild/redeploy affected applications from clean dependency lockfiles.
• Rotate proxy credentials used by vulnerable applications, especially if those applications made requests to third-party or user-controlled endpoints.
• Review proxy and destination server logs for leaked Proxy-Authorization headers during the exposure window.
• Harden outbound proxy accounts with least privilege, destination allowlists, rate limits, and monitoring for anomalous reuse.
• Add regression tests or HTTP client wrappers that prevent forwarding proxy-only headers across redirects or to non-proxy destinations.