Axios patches NO_PROXY normalization bypass enabling SSRF

TL;DR — Axios can mis-handle hostname normalization when applying NO_PROXY, causing requests to loopback/internal targets (e.g., localhost. or [::1]) to be sent through a proxy and enabling SSRF exposure.

What happened

Axios is a popular promise-based HTTP client for the browser and Node.js used broadly across application and platform tooling. CVE-2025-62718 describes a hostname normalization bypass in NO_PROXY rule evaluation: in affected releases, certain loopback forms (including localhost. with a trailing dot and the IPv6 loopback literal [::1]) can skip NO_PROXY matching and instead go through the configured proxy.

This matters because many teams rely on HTTP_PROXY/HTTPS_PROXY + NO_PROXY as a control to keep traffic to loopback, metadata endpoints, and internal services from traversing enterprise proxies. If an attacker can influence request destinations (classic SSRF precondition), this kind of canonicalization drift can turn “protected-by-NO_PROXY” assumptions into reachable internal targets.

The CVE record also includes CISA ADP “vulnrichment” metadata indicating SSVC options Exploitation=poc and Automatable=yes—a signal that this issue is plausible to operationalize in real systems, not just a theoretical edge case.

Who is impacted

• Applications and services using axios versions < 1.15.0.
• Environments that configure outbound proxies via HTTP_PROXY / HTTPS_PROXY and rely on NO_PROXY to protect loopback or internal destinations.
• Higher-risk services where attacker-controlled URLs can be fetched (webhooks, URL previewers, “import from URL”, image/icon fetchers, LLM tool fetchers), because SSRF primitives often start as “fetch this URL for me.”

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing.

  "This vulnerability is fixed in 1.15.0."

• Inventory where axios runs in production (lockfiles, container images, deployed artifacts) and prioritize patching internet-facing services that fetch attacker-influenced URLs.
• Audit proxy posture assumptions:
  • Identify services that treat NO_PROXY as an SSRF mitigation boundary for loopback/internal targets.
  • Specifically test/monitor request behavior for edge-case hostnames like localhost. and IPv6 literals such as [::1] in your environment.
• If you suspect abuse, review outbound request logs for proxy-routed traffic to loopback/internal destinations and rotate credentials reachable from the affected service (including cloud instance metadata-derived credentials where applicable).