CVE-2026-42038

What it actually does

Axios versions prior to 1.15.1 and 0.31.1 incompletely normalize hostnames when deciding whether a request should bypass a configured proxy via the no_proxy / NO_PROXY setting. If no_proxy=localhost is configured, requests made to loopback equivalents such as 127.0.0.1 or [::1] may still be sent through the proxy because shouldBypassProxy() performs direct string matching rather than resolving equivalent loopback addresses. The main technical risk is unintended disclosure of HTTP requests intended for local-only services to an upstream proxy. Integrity and availability are not directly affected by the vulnerability itself, but confidentiality can be high if loopback requests include secrets, service metadata, session material, internal API responses, or administrative endpoints.

Why it matters to the business

Applications that rely on Axios and proxy exclusions to keep local traffic private may accidentally send sensitive localhost traffic through corporate, third-party, or attacker-controlled proxies. This can expose credentials, tokens, local service responses, development tooling data, or administrative API traffic that teams expected to remain on the host. The CVSS score is moderate at 6.8 and EPSS is currently low at 0.00301, with no known CISA KEV listing or public exploit maturity reported, but the issue is common in Node.js and browser-adjacent JavaScript ecosystems where Axios is widely used, so organizations should prioritize remediation in services that use outbound proxies and make requests to loopback addresses.

How an attack unfolds

An attacker needs a situation where an affected Axios-based application uses a proxy and relies on no_proxy=localhost to prevent local traffic from traversing that proxy. The attacker may control or observe the configured proxy, compromise a proxy infrastructure component, influence proxy environment variables, or position themselves where proxy traffic can be inspected. When the vulnerable application makes Axios requests to loopback aliases such as http://127.0.0.1, https://127.0.0.1, http://[::1], or https://[::1], Axios fails to treat those destinations as equivalent to localhost. Instead of bypassing the proxy, it sends the request through the proxy. The proxy can then observe request URLs, headers, cookies, authorization tokens, request bodies, and potentially responses, depending on protocol and TLS handling. The attack is most impactful when local services expose sensitive metadata, debugging endpoints, administrative APIs, or credentials-bearing requests over loopback.

How to fix it

Upgrade Axios to a fixed release: 1.x users should upgrade to axios 1.15.1 or later, and 0.x users should upgrade to axios 0.31.1 or later. Because no exact per-package fixed version list was supplied beyond the advisory text, review direct and transitive dependencies in package-lock.json, yarn.lock, pnpm-lock.yaml, and bundled artifacts to ensure no vulnerable Axios versions remain. As a defense-in-depth mitigation, configure proxy bypass lists to include all loopback forms that applications may use, such as localhost, 127.0.0.1, ::1, [::1], and any relevant local host aliases. Avoid routing sensitive local service calls through generic proxy code paths where possible. Restrict proxy access, disable proxy logging of sensitive headers where feasible, and ensure secrets are not sent to local endpoints unless required.

How to confirm the fix worked

Confirm the installed Axios version is 1.15.1 or later for the 1.x line, or 0.31.1 or later for the 0.x line, using package manager inventory commands such as npm ls axios, yarn why axios, pnpm why axios, or software composition analysis tooling. Inspect lockfiles and container images to verify the fixed version is present in deployed artifacts, not only in source manifests. Functionally test proxy bypass behavior by setting a test proxy and no_proxy=localhost, then making Axios requests to localhost, 127.0.0.1, and [::1]; fixed versions should consistently bypass the proxy for loopback equivalents when configured to do so. Review runtime environment variables for HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY, and no_proxy to ensure bypass entries include expected loopback forms.

Typical attack path

1. Identify an application or service using a vulnerable Axios version with proxy support enabled.
2. Confirm that proxy exclusion is configured narrowly, for example no_proxy=localhost or NO_PROXY=localhost.
3. Position to observe, control, or receive traffic at the configured HTTP or HTTPS proxy, or influence the application to use an attacker-controlled proxy.
4. Cause or wait for the application to make Axios requests to loopback equivalents such as 127.0.0.1 or [::1].
5. Collect sensitive request metadata, headers, tokens, request bodies, or responses that are unintentionally routed through the proxy.
6. Use any exposed secrets or local service data for follow-on access, reconnaissance, or privilege expansion.

How to detect it

Look for evidence that Axios-based applications sent loopback traffic through an HTTP or HTTPS proxy. Primary log sources include forward proxy access logs, egress gateway logs, web proxy authentication logs, application logs that record outbound request destinations, container or process environment captures, CI job logs, and endpoint/network telemetry showing proxy-bound connections. Search proxy logs for destination URLs or Host headers containing 127.0.0.1, [::1], ::1, or localhost from application hosts. Pay particular attention to requests with Authorization, Cookie, X-API-Key, metadata, admin, debug, health, metrics, actuator, or token-related paths. Review whether HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY, or no_proxy were set at the time and whether NO_PROXY only contained localhost. Since exploitation may simply appear as legitimate proxy traffic, absence of a unique exploit string does not rule out exposure; correlate unexpected loopback proxy requests with vulnerable Axios versions and sensitive headers or responses. No named threat actors, ransomware use, or KEV exploitation are currently indicated for this CVE.

• Host: 127.0.0.1
• Host: [::1]
• Host: ::1
• http://127.0.0.1
• https://127.0.0.1
• http://[::1]
• https://[::1]
• NO_PROXY=localhost
• no_proxy=localhost
• HTTP_PROXY=
• HTTPS_PROXY=
• ALL_PROXY=
• axios/

What your security team should do

• Inventory applications, containers, serverless functions, CI jobs, and developer tooling that include Axios, especially Node.js services using HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY, or no_proxy.
• Prioritize upgrades for workloads that make Axios calls to local services, metadata endpoints, admin APIs, sidecars, agents, or development/debug interfaces while a proxy is configured.
• Upgrade to axios 1.15.1 or later, or 0.31.1 or later for projects pinned to the 0.x branch.
• Add explicit proxy bypass entries for localhost, 127.0.0.1, ::1, and [::1] as a temporary mitigation and as defense in depth after patching.
• Review proxy logs for unexpected loopback-destination requests from application hosts and investigate any requests containing credentials, authorization headers, cookies, or sensitive local API paths.
• Limit who can configure proxy environment variables in production and CI/CD execution contexts.
• Ensure proxy infrastructure masks or avoids storing Authorization, Cookie, Set-Cookie, and other sensitive headers where operationally possible.
• Because EPSS is low and the issue is not in CISA KEV, treat this as risk-prioritized patching rather than emergency response unless affected services handle secrets or local administrative interfaces.