CVE-2026-42043

What it actually does

This flaw affects Axios proxy-bypass handling for loopback addresses. When an application uses Axios and relies on NO_PROXY protection to prevent proxied requests to local services, an attacker who can control or influence the request URL can specify loopback addresses in the 127.0.0.0/8 range other than 127.0.0.1, such as 127.0.0.2 or 127.1.2.3, to bypass the intended NO_PROXY behavior. In vulnerable versions prior to Axios 1.15.1 and 0.31.1, this can allow server-side request forgery-style access to services bound to loopback interfaces, potentially exposing local-only HTTP APIs, metadata-like services, development consoles, or administrative endpoints reachable from the process running Axios.

Why it matters to the business

Applications that fetch attacker-influenced URLs with Axios may unintentionally allow access to internal or local-only services that were assumed to be protected by proxy and NO_PROXY controls. The likely impact is unauthorized reading or modification of data exposed by local services, abuse of administrative endpoints, and possible pivoting into application infrastructure. Although there is no known CISA KEV listing, no known ransomware association, and EPSS is currently low, Axios is widely used across Node.js and browser-based ecosystems, so organizations should prioritize inventory and upgrade work wherever Axios is used for URL fetching, webhooks, link previews, importers, integrations, or proxy-aware outbound HTTP requests.

How an attack unfolds

An attacker first identifies an application feature that causes the server or runtime to make an outbound Axios request to a URL the attacker can influence, such as a webhook target, image fetcher, URL preview, import connector, callback URL, or API integration setting. If the application is running a vulnerable Axios version and depends on NO_PROXY behavior to keep loopback destinations from being reached through the configured proxy path, the attacker supplies a loopback address in the broader 127.0.0.0/8 range instead of the common 127.0.0.1 address. Because the vulnerable Axios logic incompletely handles these alternate loopback representations, the request may bypass the intended NO_PROXY protection and reach services listening only on the local interface. The attacker then probes local ports and paths, observes differences in HTTP status codes, response sizes, or timing, and attempts to access sensitive endpoints, administrative APIs, local service dashboards, or unauthenticated internal functionality. Successful exploitation depends on the application allowing attacker-controlled target URLs and on valuable local services being reachable from the process using Axios.

How to fix it

Upgrade Axios to a fixed version: 1.15.1 or later for the 1.x release line, or 0.31.1 or later for the 0.x release line. Because transitive dependencies may bundle Axios indirectly, rebuild lockfiles and container images after updating package manifests. In addition to upgrading, enforce application-level SSRF controls: validate and canonicalize all user-controlled URLs before requests are made; block all loopback ranges including 127.0.0.0/8, ::1/128, IPv4-mapped IPv6 loopback, localhost names, and alternate numeric encodings; restrict outbound requests to an allowlist of expected domains; disable redirects or revalidate every redirect destination; and prevent access to private, link-local, and internal network ranges unless explicitly required. Do not rely on NO_PROXY alone as an SSRF boundary. Where possible, place outbound-fetching services in a network segment with egress filtering so they cannot reach local administrative services or sensitive internal endpoints.

How to confirm the fix worked

Confirm that dependency manifests and resolved lockfiles no longer reference vulnerable Axios versions earlier than 1.15.1 or 0.31.1. Use package manager tooling such as npm ls axios, yarn why axios, pnpm why axios, software composition analysis, or SBOM queries to identify both direct and transitive copies. Validate running artifacts, not only source repositories, by checking built containers, serverless packages, and deployed bundles. Functionally test SSRF defenses by attempting benign requests to alternate loopback addresses in 127.0.0.0/8, such as http://127.0.0.2/, http://127.1.1.1/, and http://127.255.255.255/, and confirm they are blocked before Axios sends an outbound request. Also test redirects to these addresses and hostnames resolving to loopback addresses. The fix is confirmed when vulnerable Axios versions are absent from deployed artifacts and application controls reject all loopback and internal address variants regardless of proxy or NO_PROXY configuration.

Typical attack path

1. Find an application feature that accepts a user-supplied or partially user-controlled URL and causes Axios to fetch it.
2. Confirm the application or service uses a vulnerable Axios version prior to 1.15.1 or 0.31.1, or infer vulnerability through behavior.
3. Submit a URL using an alternate loopback address in 127.0.0.0/8, such as 127.0.0.2, 127.1.1.1, or 127.255.255.255, instead of 127.0.0.1.
4. Probe common local service ports and paths through the vulnerable request flow.
5. Use response content, timing, redirects, or error behavior to map reachable loopback services.
6. Access sensitive local-only endpoints or trigger state-changing administrative actions if exposed.
7. Exfiltrate data returned by the local service or use the access as a pivot to further compromise application infrastructure.

How to detect it

Look for evidence that attacker-controlled URL-fetching features were used to request alternate loopback addresses in the 127.0.0.0/8 range other than 127.0.0.1. Useful sources include application access logs, API gateway logs, reverse proxy logs, webhook or integration audit logs, URL preview/importer logs, outbound proxy logs, DNS logs, container egress logs, and logs from local services listening on loopback interfaces. Search for URLs, Host headers, request parameters, JSON fields, error messages, and redirect targets containing 127.x.x.x values where the first octet is 127 but the full address is not exactly 127.0.0.1. Also look for probing behavior across common local ports such as 80, 443, 3000, 5000, 8000, 8080, 9000, and administrative paths such as /admin, /debug, /metrics, /actuator, /health, /api, and /config. Because exploitation may appear as normal application-initiated outbound traffic, correlate inbound requests that set or submit a URL with subsequent outbound connections from the application process to loopback addresses. If local services log requests, look for unexpected user agents associated with Axios, unusual source processes, or requests arriving at endpoints that should only be used internally.

• http://127.0.0.2
• https://127.0.0.2
• http://127.1.1.1
• https://127.1.1.1
• http://127.255.255.255
• https://127.255.255.255
• Host: 127.0.0.2
• Host: 127.1.1.1
• Host: 127.255.255.255
• User-Agent: axios
• /admin
• /debug
• /metrics
• /actuator
• /actuator/env
• /actuator/heapdump
• /health
• /config
• /api

What your security team should do

• Inventory all applications, services, containers, and build artifacts using Axios, including transitive dependencies.
• Prioritize upgrade of internet-facing features that fetch user-supplied URLs, process webhooks, generate link previews, import remote content, or integrate with external callback URLs.
• Upgrade Axios to 1.15.1 or later, or 0.31.1 or later, and regenerate lockfiles and deployed artifacts.
• Add SSRF-safe URL validation that blocks the full loopback range 127.0.0.0/8 and equivalent IPv6, DNS, redirect, and numeric-encoding variants.
• Implement outbound egress allowlisting for services that perform server-side HTTP fetches.
• Review NO_PROXY and proxy configuration, but treat it as a routing convenience rather than a security control.
• Search logs for historical requests to alternate 127.0.0.0/8 addresses and unusual local port probing patterns.
• Add automated dependency scanning and CI policy checks to prevent reintroduction of vulnerable Axios versions.
• If suspicious activity is found, review local service access logs and application responses for evidence of data exposure or state-changing requests.