CVE-2025-62718: The Trailing Dot That Leaked Your Localhost

A 9.9 in axios, published April 2026 (CVE-2025-62718): NO_PROXY=localhost does not protect http://localhost.:8080/, and it does not protect http://[::1]/ either. Axios forwards those requests through the configured HTTP proxy — a textbook SSRF pivot, delivered by the oldest bug in the book: string-compare on things that aren't strings.

The advisory in plain English

You run a service behind a corporate egress proxy. Your devs set HTTP_PROXY for outbound calls and NO_PROXY=localhost,127.0.0.1,::1 to keep internal traffic in-house — metadata endpoints, sidecars, the admin API listening on [::1]:9090. Standard hygiene.

Prior to 1.15.0 (and 0.31.0 on the v0 line), if any attacker-influenced input reached an axios request URL, they could smuggle it past the NO_PROXY allow-deny by tacking on a trailing dot (localhost.) or by wrapping the loopback address in IPv6 brackets ([::1]). Both of those strings refer to the same destination as the allow-listed host, and the kernel's resolver will happily send the packet to 127.0.0.1 / ::1 — but the axios check compared raw strings, and strings don't understand DNS. The proxy saw the CONNECT, the proxy applied its ACL, and you just rewrote your threat model.

The flawed path

Before the fix, lib/adapters/http.js outsourced the entire decision to the proxy-from-env npm package:

function setProxy(options, configProxy, location) {
  let proxy = configProxy;
  if (!proxy && proxy !== false) {
    const proxyUrl = getProxyForUrl(location);
    if (proxyUrl) {
      proxy = new URL(proxyUrl);
    }
  }

That's the whole story. getProxyForUrl(location) returns either an empty string (meaning: matched NO_PROXY, don't proxy) or a proxy URL (meaning: use this proxy). Axios trusts that verdict completely. If the third-party matcher says "proxy," axios proxies.

proxy-from-env does what its name suggests and does it literally: it splits NO_PROXY on commas, lowercases, and compares hostnames as strings (with a leading-dot suffix form for domain matching). It does not strip trailing DNS dots. It does not unwrap IPv6 bracket literals from URI authority syntax. Those are two separate normalization steps, and neither of them was anyone's job.

Why the check was insufficient

There are two orthogonal gaps.

Gap one: the trailing dot. RFC 1034 §3.1 defines the trailing dot as the syntactic marker of a fully qualified name — an absolute anchor at the DNS root. localhost and localhost. resolve to the same address. Browsers, curl, and every getaddrinfo-flavored resolver on the planet treat them as equivalent endpoints. String equality disagrees:

'localhost.' === 'localhost'   // false
'localhost.'.endsWith('.localhost')  // false

Any allow-list that indexes by raw hostname has to normalize this dot before comparing — or be wrong. proxy-from-env didn't.

Gap two: the IPv6 brackets. RFC 3986 §3.2.2 requires IPv6 literals in URIs to be wrapped in square brackets so the port colon can be disambiguated from the colons inside the address. So http://[::1]:8080/ is the only correct way to write that URL. But URL.hostname on Node.js keeps the brackets:

new URL('http://[::1]:8080/').hostname  // '[::1]'

Now compare against NO_PROXY=::1. '[::1]' === '::1' is false; the allow-list misses; the proxy wins. Again — this is a normalization step (strip the brackets) that must happen before the compare, and nobody was doing it.

Combine the two and you get a lovely matrix of miss cases: localhost., LOCALHOST, [::1], [::1]., [0:0:0:0:0:0:0:1], etc. The advisory highlights the first two because they're the ones that reach loopback without DNS games and without touching the attacker's network.

What the fix changed

Two pieces. First, setProxy grew a guard:

if (proxyUrl) {
  if (!shouldBypassProxy(location)) {
    proxy = new URL(proxyUrl);
  }
}

If proxy-from-env still returns a proxy URL, axios now asks a second, stricter question before honoring it: does my own normalization think this should bypass? If yes, drop the proxy on the floor.

Second, the new helper lib/helpers/shouldBypassProxy.js implements the normalization that was missing. The hostname canonicalizer is exactly the two lines you'd expect:

const normalizeNoProxyHost = (hostname) => {
  if (!hostname) return hostname;
  if (hostname.charAt(0) === '[' && hostname.charAt(hostname.length - 1) === ']') {
    hostname = hostname.slice(1, -1);
  }
  return hostname.replace(/\.+$/, '');
};

Strip brackets if wrapped. Strip trailing dots (plural — localhost.. was also a miss). Lowercase happens outside this helper. Both the request hostname and each NO_PROXY entry pass through normalizeNoProxyHost before they're compared, so [::1] in the URL matches ::1 in the env var, and localhost. matches localhost. The helper also learned to parse NO_PROXY entries with IPv6 brackets ([::1]:8080) and with plain host:port, and preserves the existing *, *.example.com, and .example.com semantics.

The regression tests in the same commit make the intent precise:

it('should bypass proxy for localhost with a trailing dot', () => {
  setNoProxy('localhost,127.0.0.1,::1');
  expect(shouldBypassProxy('http://localhost.:8080/')).toBe(true);
});

it('should bypass proxy for bracketed ipv6 loopback', () => {
  setNoProxy('localhost,127.0.0.1,::1');
  expect(shouldBypassProxy('http://[::1]:8080/')).toBe(true);
});

Those two assertions are the CVE, inverted.

The lesson

Three, actually.

1. An allow-list is only as strong as its normalization. Any security decision that keys on a hostname, URL, path, or email address has a canonicalization step hiding under it. If you don't write that step, you are trusting the identity function, and the identity function is wrong about approximately everything: trailing dots, Unicode, percent-encoding, case, IDN, IPv6 zone IDs, path traversal, port defaults. The CVE here is narrow; the class is wide. Apache, nginx, curl, Go's net/http, Python's urllib have all had the exact same conversation.

2. Delegating a security boundary to a utility library is delegating the threat model, too. proxy-from-env is fine for what it is: a convenience wrapper that reads env vars and returns strings. It was never a hardened ACL. Axios treated its return value as a security decision, which promoted a helper library into the TCB without promoting its test suite. The fix doesn't replace proxy-from-env — it wraps it with a second opinion that axios owns. That's the right move when you can't control the upstream: belt, suspenders, and a note about whose suspenders they are.

3. NO_PROXY is an attack surface you probably forgot you had. It's environment-driven, rarely audited, rarely tested, and it gates whether your outbound HTTP client talks to the metadata service. In a cloud instance, a NO_PROXY bypass that flips a request through an attacker-controlled proxy is a credential-theft primitive. Treat it with the seriousness of an IAM rule, not the seriousness of a formatting preference.

Update to 1.15.0 or 0.31.0. And next time you see a const entryHost = entry.toLowerCase(); in your own codebase, ask what else entry might be.

References

• NVD: CVE-2025-62718
• Advisory: https://github.com/axios/axios/security/advisories/GHSA-3p68-rc4w-qgx5
• Fix (v1): https://github.com/axios/axios/commit/fb3befb6daac6cad26b2e54094d0f2d9e47f24df
• Fix (v0 backport): https://github.com/axios/axios/commit/03cdfc99e8db32a390e12128208b6778492cee9c
• PR #10661: https://github.com/axios/axios/pull/10661
• PR #10688: https://github.com/axios/axios/pull/10688
• Release v1.15.0: https://github.com/axios/axios/releases/tag/v1.15.0
• Release v0.31.0: https://github.com/axios/axios/releases/tag/v0.31.0
• RFC 1034 §3.1 (domain name syntax, trailing dot): https://datatracker.ietf.org/doc/html/rfc1034#section-3.1
• RFC 3986 §3.2.2 (host component, IP-literal brackets): https://datatracker.ietf.org/doc/html/rfc3986#section-3.2.2