Cloudanix VulnDB

CVE-2025-62718

Critical · 9.9

CVSS

9.9

EPSS

1.2%

Published

Apr 9, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A widely used web request library could send supposedly protected local or internal requests through a proxy, allowing attackers to reach systems that were meant to stay private.

Chainable
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Moderate
Impact
Data Exposure
Component
Library
Class
SSRF
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Axios versions prior to 1.15.0 and 0.31.0 incorrectly compare hostnames against NO_PROXY rules without fully normalizing certain loopback representations. Hostnames such as localhost. with a trailing dot or IPv6 literals such as [::1] may fail NO_PROXY matching and be sent through the configured HTTP proxy even when developers intended loopback or internal destinations to bypass the proxy. In applications where attackers can influence URLs fetched by Axios, this can weaken SSRF defenses, expose loopback-only or internal services through proxy-mediated requests, and cause requests to reach destinations that proxy and application policy were expected to block.

Why it matters to the business

Applications using affected Axios versions may unintentionally allow attacker-supplied requests to reach internal or loopback services, potentially exposing administrative endpoints, local service APIs, cloud metadata services, secrets, or internal-only data. The CVSS score is critical, but EPSS is currently low and it is not listed in CISA KEV, so prioritization should focus on internet-facing applications, services that fetch user-controlled URLs, and environments that rely on NO_PROXY to protect internal destinations.

How an attack unfolds

An attacker first identifies an application feature that causes the server to make outbound HTTP requests using Axios, such as URL preview, webhook delivery, document import, image fetching, API integration testing, or metadata retrieval. If the application relies on proxy configuration and NO_PROXY entries to prevent loopback or internal requests from being proxied, the attacker supplies a specially formatted loopback or internal URL such as one using localhost. with a trailing dot or an IPv6 loopback literal. A vulnerable Axios version fails to match the hostname against NO_PROXY as intended and sends the request through the configured proxy. If the proxy can reach the target service or reveals request/response details back to the application, the attacker may access internal endpoints, enumerate services, retrieve sensitive metadata, or interact with local administrative APIs that were assumed unreachable.

How to fix it

Upgrade Axios to a fixed release: 1.15.0 or later for the 1.x line, or 0.31.0 or later for the 0.x line. Because Axios is frequently included as a transitive dependency, inspect package lockfiles and dependency trees and use package-manager overrides or resolutions where necessary until upstream packages update. Rebuild and redeploy affected applications after dependency updates. As defense in depth, implement SSRF controls outside Axios: use strict allowlists for outbound destinations, normalize and canonicalize hostnames before policy checks, block loopback, link-local, private, and cloud metadata address ranges at the application and proxy layers, and configure egress proxies to deny requests to localhost, loopback, RFC1918, link-local, and metadata IP ranges regardless of client behavior.

How to confirm the fix worked

Confirm that all deployed packages resolve Axios to 1.15.0 or later, or 0.31.0 or later on the legacy branch, using dependency inspection such as npm ls axios, yarn why axios, pnpm why axios, software composition analysis, or lockfile review. Add regression tests that attempt Axios requests to localhost., [::1], 127.0.0.1, and other internal host forms while a proxy and NO_PROXY are configured; the requests should not be sent through the proxy when covered by NO_PROXY and should be blocked by SSRF policy where applicable. Validate proxy enforcement by checking that proxy logs show no successful traffic to loopback, private, link-local, or metadata destinations from application workloads.

Typical attack path

  1. Find an application endpoint or workflow that accepts a URL or hostname and fetches it server-side using Axios.
  2. Confirm or infer that the application uses an HTTP proxy and depends on NO_PROXY to exclude loopback or internal hosts.
  3. Submit a crafted URL using hostname forms such as localhost. or [::1] that should be treated as loopback but may not match NO_PROXY rules.
  4. Cause vulnerable Axios code to route the request through the configured proxy instead of bypassing it.
  5. Use the proxied request path to reach loopback, internal, or otherwise protected services.
  6. Collect returned data, trigger internal actions, or iterate across additional internal endpoints if responses are exposed.

How to detect it

Investigate whether applications accepted externally supplied URLs and made outbound Axios requests through a proxy while running affected versions. Review application request logs for user-supplied URLs containing loopback variants, trailing-dot hostnames, IPv6 literals, cloud metadata addresses, or internal service names. Review HTTP proxy logs for requests from application servers to localhost., localhost, [::1], ::1, 127.0.0.1, private IP ranges, link-local ranges, and metadata endpoints. Correlate suspicious inbound requests that include crafted URLs with near-time outbound proxy requests to internal destinations. Inspect application error logs for failed connection attempts, SSRF validation bypass attempts, or proxy connection messages involving loopback and internal addresses. In containerized or cloud environments, also review egress proxy, service mesh, NAT gateway, DNS, and metadata service access logs for unexpected internal access attempts from application workloads.

  • localhost.
  • http://localhost.
  • https://localhost.
  • http://localhost./
  • https://localhost./
  • [::1]
  • http://[::1]
  • https://[::1]
  • 127.0.0.1
  • http://127.0.0.1
  • 169.254.169.254
  • http://169.254.169.254
  • metadata.google.internal
  • 169.254.169.254/latest/meta-data
  • 169.254.169.254/metadata/instance
  • NO_PROXY
  • HTTP_PROXY
  • HTTPS_PROXY

What your security team should do

  • Prioritize patching internet-facing services and any service that fetches user-supplied URLs with Axios.
  • Upgrade Axios to 1.15.0 or later, or 0.31.0 or later for legacy 0.x deployments, including transitive dependency instances.
  • Search codebases for Axios-based outbound fetch functionality and verify that SSRF protections do not depend solely on NO_PROXY.
  • Harden egress proxies and firewalls to block loopback, private address space, link-local ranges, and cloud metadata endpoints by policy.
  • Add application-level URL canonicalization and destination allowlisting before any outbound request is made.
  • Review proxy, application, and web access logs for suspicious requests containing localhost., [::1], or attempts to access metadata/internal endpoints.
  • Add regression tests and CI dependency checks so vulnerable Axios versions are not reintroduced.

The record

Axios is a promise based HTTP client for the browser and Node.js. Prior to 1.15.0 and 0.31.0, Axios does not correctly handle hostname normalization when checking NO_PROXY rules. Requests to loopback addresses like localhost. (with a trailing dot) or [::1] (IPv6 literal) skip NO_PROXY matching and go through the configured proxy. This goes against what developers expect and lets attackers force requests through a proxy, even if NO_PROXY is set up to protect loopback or internal services. This issue leads to the possibility of proxy bypass and SSRF vulnerabilities allowing attackers to reach sensitive loopback or internal services despite the configured protections. This vulnerability is fixed in 1.15.0 and 0.31.0.

Affected packages

Ecosystem Package Introduced Fixed
npm axios 0 0.31.0
npm axios 1.0.0 1.15.0

Related vulnerabilities