CVE-2026-42038: Server-Side Request Forgery via Incomplete Hostname Normalization in Axios Proxy Logic

Axios is a widely utilized promise-based HTTP client for Node.js and browser environments. In server-side deployments, administrators frequently configure upstream proxies using environment variables such as HTTP_PROXY. To prevent internal traffic from routing through these external proxies, Axios supports the NO_PROXY environment variable to define exclusion lists.

The vulnerability resides in the shouldBypassProxy() function, which evaluates whether a requested URL matches any entries in the exclusion list. Prior to versions 1.15.1 and 0.31.1, this function utilized literal string comparisons and simple suffix matching. It failed to implement semantic normalization for network addresses.

Consequently, the logic did not recognize that hostnames like localhost, 127.0.0.1, and [::1] resolve to the same loopback interface. This omission creates a Server-Side Request Forgery (CWE-918) condition. Internal requests targeting a loopback alias not explicitly listed in the NO_PROXY variable are incorrectly forwarded to the configured external proxy.

The root cause of this vulnerability is the absence of network protocol semantics in the hostname comparison implementation. The shouldBypassProxy.js utility evaluates bypass rules by checking if the target hostname strictly equals the bypass entry or ends with the bypass entry string. This approach is effective for standard domain names but fails for semantic IP equivalents.

When a developer configures NO_PROXY=localhost to ensure local administrative traffic remains on the host system, the application creates a bypass rule for the exact literal string "localhost". If the application subsequently attempts to connect to 127.0.0.1 or [::1], Axios processes the bypass rules sequentially.

The comparison hostname === entryHost evaluates to "127.0.0.1" === "localhost", which returns false. Because no semantic normalization step exists to resolve these hostnames to their underlying interface definitions prior to comparison, Axios determines that the request does not qualify for proxy bypass. The request is subsequently packaged and dispatched to the upstream proxy defined in HTTP_PROXY.

The original implementation of shouldBypassProxy() relied on naive string manipulation. The relevant pseudo-logic performed a direct equivalence check against the configured exclusion variables. This implementation failed to account for standard IPv4 and IPv6 aliases for the local machine.

The maintainers addressed this vulnerability in commit 163da7226fd2cd21f0f238f99b2f75a51bf9b2a3 by introducing explicit awareness of loopback addresses. The fix establishes a Set constant named LOOPBACK_ADDRESSES containing the standard aliases: localhost, 127.0.0.1, and ::1.

const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);

The evaluation logic within shouldBypassProxy() was then expanded to include a semantic check alongside the literal check. The updated conditional statement ensures that if both the requested hostname and the bypass entry belong to the loopback set, the proxy is bypassed.

export default function shouldBypassProxy(location) {
  // ...
  return noProxyEntries.some(entry => {
    // ...
    // Updated logic now equates loopback aliases
    return hostname === entryHost || (isLoopback(hostname) && isLoopback(entryHost));
  });
}

This fix successfully patches the vulnerability by enforcing semantic equivalence for the local interface. However, it does not generalize to other IP aliases or subnets. Developers must still ensure that non-loopback IPs and their corresponding domain names are explicitly declared in the exclusion lists.

Exploitation requires specific environmental preconditions. The targeted Node.js application must utilize a vulnerable version of Axios, operate with an upstream proxy configured via HTTP_PROXY, and use NO_PROXY=localhost to isolate local endpoints. The attacker must possess the ability to supply or manipulate the URL queried by the Axios client.

To execute the attack, the adversary inputs a URL targeting the local interface using an alias that is not explicitly present in the NO_PROXY list. For example, the attacker submits http://127.0.0.1/admin/debug to an endpoint that fetches URLs via Axios. The developer assumed the localhost rule would protect this request.

Axios processes the target hostname 127.0.0.1. The proxy bypass string literal comparison fails. Axios establishes a connection to the configured upstream proxy and forwards the entire HTTP request, including sensitive path information and internal headers. If the upstream proxy is attacker-controlled or monitored, the internal data is compromised.

This vulnerability carries a CVSS v3.1 score of 6.8 (Medium), reflecting the conditional nature of the exploit and its specific requirements. The impact is primarily assessed as High Confidentiality (C:H). By routing internal traffic through an external proxy, sensitive data intended exclusively for the local host is leaked to an external party.

The data exposed in this SSRF variant depends heavily on the application's functionality. It often includes internal API tokens, unauthenticated administrative panel responses, and localized database queries. Because the request originates from the targeted server and is sent to the proxy, the proxy operator can inspect the raw HTTP request.

The EPSS score is recorded at 0.00044, indicating a low probability of broad automated exploitation. This aligns with the necessity for specific environment variables and application architectures. No active exploitation has been observed in the wild, and CISA has not listed this CVE in the Known Exploited Vulnerabilities (KEV) catalog.

The primary remediation strategy is upgrading Axios to a patched release. Development teams must identify dependencies utilizing Axios and update their package manifests to require version 1.15.1, version 0.31.1, or later. Following the package update, process restarts are required to ensure the modified proxy logic is loaded into memory.

In environments where upgrading the library is not immediately feasible, system administrators can apply a configuration workaround. Expanding the NO_PROXY or no_proxy environment variables to explicitly enumerate all loopback variants mitigates the vulnerability.

Administrators should execute export no_proxy="localhost,127.0.0.1,::1" within the deployment environment. Additionally, developers can explicitly disable proxy usage for critical internal requests by setting proxy: false directly in the Axios request configuration object, bypassing the environmental proxy checks entirely.