May 5, 2026·6 min read·24 visits
Axios fails to validate the full 127.0.0.0/8 loopback subnet, allowing attackers to supply non-standard local IPs (e.g., 127.0.0.2) to bypass NO_PROXY rules and maliciously route internal traffic through external proxies.
Axios versions prior to 1.15.1 and 0.31.1 contain a security control bypass vulnerability in the `NO_PROXY` implementation. The issue originates from an incomplete fix for a previous vulnerability (CVE-2025-62718). By targeting non-standard loopback IP addresses within the 127.0.0.0/8 subnet, an attacker can bypass internal traffic protections and force Axios to route requests through an external proxy. This results in Server-Side Request Forgery (SSRF) and Confused Deputy attacks.
Axios is a widely used promise-based HTTP client for browser and Node.js environments. Applications frequently configure Axios to use an external proxy via the HTTP_PROXY environment variable for outbound traffic. To prevent internal or local traffic from being sent to the external proxy, developers utilize the NO_PROXY environment variable.
The vulnerability exists in the parsing logic responsible for determining if a target hostname represents a local interface. This defect constitutes a Permissive List of Allowed Inputs (CWE-183). The shouldBypassProxy helper fails to properly identify the complete IP space reserved for loopback operations.
Because Axios does not correctly identify these addresses, it routes the traffic to the configured external proxy rather than accessing the resource directly. This behavior allows attackers to execute a Server-Side Request Forgery (SSRF) and manipulate the proxy server into acting as a Confused Deputy (CWE-441, CWE-918).
The fundamental flaw resides within the isLoopback helper function located in lib/helpers/shouldBypassProxy.js. This logic is invoked when a requested URL does not literally match any of the hostnames specified in the NO_PROXY list. In such cases, the library falls back to verifying if both the target hostname and the NO_PROXY entry are loopback addresses.
In the vulnerable versions, the application implemented this check using a hardcoded JavaScript Set containing only three string literals: localhost, 127.0.0.1, and ::1. The validation logic relied entirely on strict equality (Set.has()) against the requested hostname. This approach violates RFC 1122 §3.2.1.3, which designates the entire 127.0.0.0/8 block for loopback routing.
When an attacker supplies a target URL using an alternative loopback address such as 127.0.0.2 or 127.10.10.10, the Set.has() check returns false. Axios concludes the target is a remote external host. Consequently, it applies the global proxy settings and forwards the request to the upstream HTTP_PROXY.
The vulnerable implementation of the loopback verification utilized a highly restricted explicit allowlist. The code specifically checked for exact string matches, failing to account for IP subnets or routing equivalence.
// Vulnerable Implementation
const LOOPBACK_ADDRESSES = new Set(['localhost', '127.0.0.1', '::1']);
const isLoopback = (host) => LOOPBACK_ADDRESSES.has(host);The patched versions (1.15.1 and 0.31.1) remove the reliance on the static literal set for IPv4 addresses. Instead, the developers implemented a parsing routine that splits the hostname and checks the leading octet. This correctly identifies any address originating in the 127 block.
// Patched Implementation (Conceptual Logic based on Commit)
const isLoopback = (host) => {
if (host === 'localhost' || host === '::1') return true;
const parts = host.split('.');
if (parts.length === 4 && parts[0] === '127') {
return parts.every(p => !isNaN(parseInt(p, 10)) && p >= 0 && p <= 255);
}
return false;
};This update fundamentally resolves the logical gap left by the prior incomplete patch (CVE-2025-62718). By evaluating the mathematical constraints of the IPv4 structure rather than relying on string literals, the fix ensures comprehensive coverage of the RFC 1122 specification.
Exploiting this vulnerability requires specific environmental preconditions. The target application must utilize Axios for making outbound HTTP requests, have an active proxy configured (via HTTP_PROXY or Axios config), and rely on NO_PROXY to shield local services. Crucially, the application must process attacker-controlled input to dictate the destination URL of an Axios request.
The attacker crafts a payload utilizing a non-standard loopback address within the 127.0.0.0/8 subnet. For instance, the attacker provides http://127.0.0.2:6379/ as the URL input. Because Axios fails to recognize this as a loopback address, it ignores the NO_PROXY directive intended to keep local traffic internal.
The request is subsequently transmitted to the external proxy server. If the proxy server lacks its own localized protections, it processes the request and routes it based on its own network perspective. The proxy acts as a Confused Deputy, allowing the attacker to probe the proxy's internal network or access services bound to the proxy's localhost interface.
The vulnerability carries a CVSS 3.1 Base Score of 7.2 (High). The attack vector is strictly network-based and requires no elevated privileges or user interaction. The primary impact relates to confidentiality and integrity, as attackers can leverage the proxy infrastructure to interact with unauthorized services.
The scope is categorized as 'Changed' because the vulnerable application (Axios) is used to pivot an attack against a secondary infrastructure component (the proxy server). The extent of the compromise depends entirely on the network placement and configuration of the external proxy. If the proxy has access to sensitive backend APIs or administrative consoles, the damage can be substantial.
However, the vulnerability does not directly permit arbitrary code execution or denial of service against the Node.js application hosting Axios. The overall impact is bounded by the capabilities and reach of the targeted proxy server, limiting the exploitability in highly segmented zero-trust environments.
The definitive remediation strategy is upgrading the Axios dependency to a patched version. Development teams must ensure their package manifest specifies Axios version 1.15.1, version 0.31.1, or later. Upgrading eliminates the vulnerability at the root cause by introducing correct subnet parsing logic.
If an immediate library upgrade is not feasible, administrators can implement configuration-based workarounds. The NO_PROXY environment variable should be updated to explicitly include the entire loopback CIDR block (127.0.0.0/8). In environments where CIDR notation is not supported by the underlying parsing logic, proxy support can be programmatically disabled for specific request flows by passing proxy: false within the Axios configuration object.
Application developers must also enforce rigorous input validation on all user-supplied URLs. Applications should reject explicit IP addresses in target URLs unless absolutely required. Implementing an architectural pattern that resolves hostnames prior to invoking the HTTP client provides an additional layer of defense against SSRF vectors.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
Axios axios | < 0.31.1 | 0.31.1 |
Axios axios | >= 1.0.0, < 1.15.1 | 1.15.1 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-183, CWE-441, CWE-918 |
| Attack Vector | Network |
| CVSS v3.1 | 7.2 |
| EPSS Score | 0.00044 |
| Impact | SSRF / Confused Deputy |
| Exploit Status | Proof of Concept |
| KEV Status | Not Listed |
The software uses a permissive list of allowed inputs to validate network addresses, failing to recognize alternative representations of loopback addresses.