CVE-2026-44492: Axios NO_PROXY IPv4-Mapped IPv6 Bypass Vulnerability (CVSS 8.6)
Axios, a widely-used HTTP client library for JavaScript, contains a bypass vulnerability in its proxy filtering logic. When developers configure Axios to skip the proxy for certain internal IP addresses (via the NO_PROXY setting), an attacker can circumvent that restriction by using an IPv4-mapped IPv6 address format. For example, if 127.0.0.1 is marked as no-proxy, a request to ::ffff:7f00:0:1 still routes through the proxy, potentially exposing internal services. Node.js resolves these IPv6 addresses back to their underlying IPv4 form, so the request reaches the intended internal host while also passing through the proxy infrastructure—defeating the security boundary the no-proxy list was meant to enforce.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.6 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
- Weaknesses (CWE)
- CWE-289, CWE-918
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-11 / 2026-07-17
NVD description (verbatim)
Axios is a promise based HTTP client for the browser and Node.js. Prior to 0.32.0 and 1.16.0, Axios does not normalise IPv4-mapped IPv6 addresses. When NO_PROXY lists an IPv4 address such as 127.0.0.1 or 169.254.169.254, a request URL using the IPv4-mapped IPv6 form (::ffff:7f00:1, ::ffff:a9fe:a9fe) still routes through the configured proxy. Node.js resolves these addresses to the underlying IPv4 host, so the request reaches the internal service via the proxy rather than being blocked. This vulnerability is fixed in 0.32.0 and 1.16.0.
34 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
Axios versions prior to 0.32.0 (for the 0.x branch) and 1.16.0 (for the 1.x branch) fail to normalize IPv4-mapped IPv6 addresses when evaluating the NO_PROXY environment variable and configuration. IPv4-mapped IPv6 addresses follow the format ::ffff:x.x.x.x (or in hexadecimal, ::ffff:xxxx:xxxx). The library compares the request URL's host against the no-proxy list without converting IPv4-mapped IPv6 addresses to their canonical IPv4 form, so entries like 127.0.0.1 do not match requests to ::ffff:7f00:0:1. Because Node.js transparently resolves IPv4-mapped IPv6 addresses to their IPv4 equivalents at the socket level, the proxy connection is still attempted, and the underlying IPv4 service receives the request via that proxy path. This violates the intended isolation of internal services from external proxy infrastructure.
Business impact
Organizations relying on Axios with proxy bypass configurations to isolate internal services may face unintended exposure of those services. Internal endpoints—such as metadata services (169.254.169.254), local application servers, or administrative interfaces—that should bypass the proxy can be inadvertently routed through external or untrusted proxy infrastructure. This could allow attackers within the network perimeter to exfiltrate data, inject payloads, or perform reconnaissance on services that were meant to be isolated. The impact is particularly severe for containerized and cloud environments where metadata services are common attack targets.
Affected systems
Applications using Axios versions 0.x prior to 0.32.0 and 1.x prior to 1.16.0 are affected. This includes any Node.js application or frontend project bundling Axios that relies on NO_PROXY configuration to restrict proxy usage for internal IPs. The vulnerability is relevant across web servers, microservices, Lambda functions, and containerized deployments that use Axios for HTTP requests.
Exploitability
Exploitation is straightforward and requires no special privileges. An attacker with network access to an Axios application can craft a URL using an IPv4-mapped IPv6 address (e.g., replacing 127.0.0.1 with ::ffff:7f00:0:1) to bypass the no-proxy list. No authentication, user interaction, or complex exploit chains are needed. The CVSS 3.1 score of 8.6 (HIGH) reflects the ease of exploitation (network-accessible, no prerequisites) and the potential for high confidentiality impact. However, it is not in CISA's Known Exploited Vulnerabilities catalog at this time, indicating limited evidence of active, weaponized exploitation in the wild.
Remediation
Upgrade Axios to version 0.32.0 or later (for 0.x users) or version 1.16.0 or later (for 1.x users). Both releases include normalization logic to canonicalize IPv4-mapped IPv6 addresses before comparing against the NO_PROXY list. After patching, verify that your application's package-lock.json or yarn.lock reflects the updated version, and conduct smoke testing of proxy bypass behavior in your environment.
Patch guidance
Identify all applications and dependencies that vendor Axios. Use npm audit, yarn audit, or SCA tooling to detect affected versions. Schedule patching in line with your change management process. For 0.x-branch users, upgrade to 0.32.0+. For 1.x-branch users, upgrade to 1.16.0+. Test in a staging environment first, particularly if your application relies on proxy-bypass logic for internal service communication. Automated CI/CD dependency scanning can help prevent future inclusion of vulnerable versions.
Detection guidance
Review application manifests (package.json) for Axios versions < 0.32.0 or < 1.16.0. Monitor for HTTP requests to IPv4-mapped IPv6 addresses (::ffff: prefix) originating from your applications, which could indicate attempted exploitation. Check proxy logs for connections to internal IP ranges that should have been bypassed, and correlate with application logs to identify which Axios-based service is the source. SIEM rules matching IPv4-mapped IPv6 addresses in HTTP clients may surface suspicious activity.
Why prioritize this
This vulnerability merits prompt attention despite its non-KEV status due to its high CVSS score (8.6), ease of exploitation, and direct impact on isolation of internal services in modern cloud and containerized environments. The bypass of NO_PROXY configuration undermines a fundamental security control. Patching is straightforward and carries low risk. Organizations should prioritize this in their patch cycle, especially those using Axios in container orchestration, serverless, or microservices architectures where metadata and admin services are prevalent.
Risk score, explained
The CVSS 3.1 score of 8.6 (HIGH, vector AV:N/AC:L/PR:N/UI:N/S:C) reflects: network-accessible attack vector, low attack complexity, no privileges or user interaction required, and changed scope (proxy infrastructure involvement affects broader system context). Confidentiality impact is high—internal services can be exposed. Integrity and availability impacts are scored as none in the base vector, though downstream exploitation of exposed services could elevate those. The score does not account for organizational reliance on proxy-bypass controls or cloud-native threat models where this bypass is particularly damaging.
Frequently asked questions
How do I know if my application is vulnerable?
Check your package.json or lock file for Axios version. If you have Axios < 0.32.0 (0.x branch) or < 1.16.0 (1.x branch), and your application uses NO_PROXY environment variables or configuration to bypass proxies for internal IPs, you are vulnerable. Run 'npm list axios' to confirm the installed version.
Can I work around this without upgrading?
A temporary workaround is to enforce proxy-bypass logic at the network level (firewall rules, network policies in Kubernetes) rather than relying solely on Axios configuration. However, this is not a substitute for patching. The root-cause fix—IPv6 normalization in Axios—should be applied as soon as feasible.
Does this vulnerability affect my front-end JavaScript if it runs in a browser?
Axios is used in both browser and Node.js environments. In browsers, the proxy-bypass logic depends on the browser's native HTTP stack and NO_PROXY settings, which may differ from Node.js behavior. However, any browser-based Axios applications that explicitly configure proxy-bypass settings are still vulnerable to the same IPv4-mapped IPv6 bypass technique. Patching is still recommended.
What is an IPv4-mapped IPv6 address and why does this matter?
An IPv4-mapped IPv6 address is a way to represent an IPv4 address in IPv6 format, using the prefix ::ffff: followed by the hexadecimal IPv4 address (e.g., ::ffff:7f00:0:1 for 127.0.0.1). Node.js transparently resolves these to their underlying IPv4 form at the network level. Axios did not normalize these addresses before checking the NO_PROXY list, so an attacker could use the IPv6 form to bypass the proxy-bypass rule.
This analysis is provided for informational purposes to assist security professionals in vulnerability assessment and risk management. The vulnerability details, affected versions, and patch information are derived from the CVE record and vendor advisories. Organizations should verify patch availability and test updates in their specific environments before deployment. SEC.co makes no warranty regarding the completeness or accuracy of this analysis and shall not be liable for any direct or indirect damages arising from its use. Always refer to the official vendor security advisory for definitive patch guidance and compatibility information. Source: NVD (public-domain), retrieved 2026-07-20. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-10068HIGHSSRF in Shibby Tomato 1.28 miniupnpd (Unmaintained)
- CVE-2026-10107HIGHMoviePilot v2 SSRF in Image Proxy Allows Internal Network Access
- CVE-2026-10280HIGHServer-Side Request Forgery in Horizon921 mcpilot 0.1.0
- CVE-2026-10287HIGHSSRF in SourceCodester SEO Meta Tag Extractor 1.0
- CVE-2026-10586HIGHGutenberg Essential Blocks SSRF Vulnerability – High Risk Server-Side Request Forgery
- CVE-2026-10771HIGHCRMEB Java SSRF Vulnerability in QR Code Endpoint
- CVE-2026-11437HIGHServer-Side Request Forgery in go-fastdfs-web 1.3.7 and Earlier
- CVE-2026-20252HIGHSplunk SSRF in Dashboard Studio PDF Export – Full Analysis