axios CVE-2026-67315

Exploitation requires all five of the following conditions simultaneously: (1) axios is running in Node.js using the HTTP adapter - not in a browser, React Native, or fetch-based context; (2) the process environment has HTTP_PROXY or HTTPS_PROXY set to a reachable proxy; (3) NO_PROXY is configured with canonical loopback entries such as localhost, 127.0.0.1, or ::1 but does not explicitly include 0.0.0.0; (4) an attacker can influence the URL supplied to axios, whether through direct user input, attacker-controlled redirects, or injected configuration; (5) the configured proxy can reach or relay traffic to 0.0.0.0 on the host and does not itself block such destinations. Exploitation is significantly limited for HTTPS targets because axios uses CONNECT tunneling, which reduces the proxy's ability to inspect request content. Applications that construct axios URLs entirely from internal logic without user-influenced data are not exploitable regardless of proxy configuration.

The CVSS 4.0 base score of 6.9 is driven by AV:N/AC:L/AT:P/PR:N/UI:N with subsequent-system confidentiality impact SC:H. The AT:P (attack requirements present) metric is the critical moderating factor: exploitation demands a specific four-way configuration conjunction - Node.js HTTP adapter, active HTTP_PROXY or HTTPS_PROXY environment variables, NO_PROXY restricted to canonical loopback forms, and attacker-controlled URL input. Any single missing condition blocks the attack. EPSS data was not provided in the intelligence feed; no KEV listing and no public POC are confirmed, suggesting opportunistic mass exploitation is not currently observed. Real-world risk is meaningful for Node.js server-side applications that proxy external requests on behalf of users (SSR apps, API gateways, scraping services), where the attacker-controlled URL precondition is commonly met. For applications that make only internally constructed requests, risk is materially lower. The CVSS signal of SC:H correctly captures that local service exposure - not the axios process itself - is the primary impact.

An attacker submits a crafted URL containing http://0.0.0.0:<port>/ to a Node.js application that accepts user-controlled URLs and uses axios to fetch them - for example, a server-side rendering service or webhook tester. Because axios does not classify 0.0.0.0 as a loopback address, the request is routed through the application's configured HTTP proxy rather than being sent directly and blocked by NO_PROXY rules. The proxy, which has network reach to the host's local services, relays the request to the local port and returns the response - including headers, authentication tokens, or internal API data - to the attacker. No public POC is confirmed at time of analysis, but the technique requires only standard HTTP tooling.