CVE-2026-75931: Host Confusion and SSRF Bypass via Scheme-Relative URIs in fast-uri

The vulnerability, tracked as CVE-2026-75931, originates from an inconsistency within the IDN (Internationalized Domain Name) parsing mechanics of fast-uri. fast-uri is a highly optimized, light-weight URI parser designed for rapid parsing and serialization operations in Node.js applications. In modern network environments, it is often utilized inside high-throughput routers, proxy servers, and API gateways to validate URLs against access policies, denylists, or SSRF (Server-Side Request Forgery) protection lists.

A flaw exists in how the parser canonicalizes or normalizes hostnames containing non-ASCII unicode characters, such as fullwidth or compatibility characters (like \u3002, representing an ideographic period). Under normal circumstances, absolute URIs with explicit schemes (e.g., http://...) are processed correctly, converting non-ASCII hostnames to their ASCII/Punycode representations. However, when evaluating scheme-relative URI references (e.g., //127\u30020\u30020\u30021/), the validation engine bypasses this canonicalization entirely.

This omission leads to an interpretation conflict (CWE-436) when the parsed or resolved output of fast-uri is handled by a standard-compliant HTTP client (like Node's native fetch or http modules) that enforces strict WHATWG standards. The validation system assesses an uncanonicalized hostname, while the transport client resolves and requests the actual canonicalized target, rendering security policies completely ineffective against host-obfuscated payloads.

The root cause of this vulnerability lies in the conditional execution of the host canonicalization logic within fast-uri's parsing loop. In vulnerable versions, the library only invoked its internal host-normalization function when the parser encountered an explicit protocol scheme during the initialization step. This implementation flaw assumed that any URI reference lacking a scheme did not immediately require Punycode translation or host-structural checks.

During the execution of resolve(), the library merges a base URI (e.g., http://trusted.example/base) and a relative URI (e.g., //127\u30020\u30020\u30021/private). The processing logic leverages a component-based parsing function resolveComponent() to resolve path, query, and authority elements. Because the relative reference starts with dual slashes (//) rather than an explicit protocol, the parser categorizes it as a scheme-relative reference.

Consequently, resolveComponent() parses the host string without triggering any IDN-to-Punycode canonicalization steps. When the library subsequently combines the base URL's scheme with the relative component's host to formulate the fully resolved URL, it merges the uncanonicalized host string verbatim into the serialized result. The final string retains characters like \u3002 (ideographic full stop) instead of translating them to standard dots (.), which allows the input to evade naive string matching or regular-expression-based destination filters.

To illustrate the vulnerability, we can examine the structural differences in how fast-uri handles resolving operations. In vulnerable releases, the host canonicalization function was only run within parseWithStatus() under restricted criteria. The resolve() method combined strings without validating whether the output host was normalized.

Below is an overview of the vulnerable resolving flow compared to the remediated logic introduced in the patch:

// VULNERABLE PATHWAY
function resolve (baseURI, relativeURI, options) {
  // Parsing happens independently for base and relative components
  const baseParsed = parse(baseURI, options)
  const relativeParsed = parse(relativeURI, options)
  
  // MERGING COMPONENT WITHOUT HOST CANONICALIZATION CHECK
  // Since relativeParsed did not have an explicit scheme, its host was left unnormalized
  const resolved = resolveComponent(baseParsed, relativeParsed, schemelessOptions, true)
  
  // Directly serialized and returned without validating host ASCII representations
  return serialize(resolved, schemelessOptions)
}

The patch fixes this vulnerability by intercepting the resolving process immediately after the base and relative elements are unified, ensuring that host normalization is executed relative to the final effective scheme:

// REMEDIATED PATHWAY
function resolve (baseURI, relativeURI, options) {
  const baseParsed = parse(baseURI, options)
  const relativeParsed = parse(relativeURI, options)
  
  // Merging components
  const resolved = resolveComponent(baseParsed, relativeParsed, schemelessOptions, true)
  
  // RESOLVED PATCH: Explicitly fetch scheme handler for final merged scheme
  const resolvedSchemeHandler = getSchemeHandler((options && options.scheme) || resolved.scheme)
  const resolvedHost = resolved.host
  const resolvedHostIsIP = resolvedHost !== undefined && resolvedHost !== '' &&
    (isIPv4(resolvedHost) || normalizeIPv6(resolvedHost).isIPV6)
    
  // Force hostname canonicalization using final resolved context
  canonicalizeHost(resolved, options || {}, resolvedSchemeHandler, resolvedHostIsIP)
  
  // Fail closed if hostname cannot be successfully mapped to ASCII
  if (resolved.error && !encodedASCIIHost) {
    throw new Error(resolved.error)
  }
  
  schemelessOptions.skipEscape = true
  return serialize(resolved, schemelessOptions)
}

This structural modification guarantees that any host output resulting from resolve() will be canonicalized or will fail hard, preventing interpretation mismatches before serialization occurs.

Exploiting this flaw requires an application architecture where input parsing and security enforcement are decoupled from actual networking actions. The threat actor must identify an endpoint that accepts a relative or absolute URL, resolves it against an internal or default base context using fast-uri, performs a validation check against the resolved host, and then initiates an HTTP request to the same URL using Node's standard fetch, axios, or native http modules.

To execute the exploit, the attacker crafts a scheme-relative payload utilizing Unicode equivalents of standard IP address delimiters:

//127\u30020\u30020\u30021/sensitive-endpoint

When processed through fast-uri's resolve function on a vulnerable library, the result is output as http://127\u30020\u30020\u30021/sensitive-endpoint. If the application extracts the hostname using the same library, it will retrieve the string "127\u30020\u30020\u30021".

Because this string does not match standard loopback patterns (e.g., 127.0.0.1 or localhost), the SSRF checks are successfully bypassed. However, once passed to Node's internal URL implementation during the outgoing HTTP call, the WHATWG parser converts the fullwidth full stop characters (\u3002) into standard periods (.), resolving the hostname directly to the loopback interface (127.0.0.1) and allowing unauthorized access to internal resources.

The impact of CVE-2026-75931 is high (CVSS v3.1 Base Score of 7.5), primarily threatening the integrity and isolation of private internal network services. In microservice architectures, API gateways and proxies often rely on lightweight parsers like fast-uri to guarantee low-latency validation of external inputs. Exploiting this vulnerability allows bypass of administrative filters, network isolation boundaries, and security policies.

If successfully exploited, an attacker can coerce the server into requesting endpoints on its own local interfaces or internal subnets (e.g., Amazon EC2 metadata services at http://169.254.169.254 or internal databases). Depending on the endpoints exposed internally, this can lead to unauthorized configuration changes, exposure of environment variables, credential leaks, or execution of administrative operations.

Furthermore, because equal() and normalize() functions yield inconsistent outputs depending on whether the scheme is explicit, secondary exploits could involve cache-key manipulation or session-hijacking in configurations where fast-uri normalization is utilized to generate lookup keys for security-sensitive contexts.

Mitigating CVE-2026-75931 permanently requires updating fast-uri to patched releases. The OpenJS Foundation has issued updates across all active major branches of the library. Security administrators must identify any dependency lockfiles incorporating versions in the affected ranges and force an immediate upgrade.

For environments unable to update the library immediately, two main workarounds exist. First, you can force host canonicalization prior to checking policies by parsing the resolved URL with the native Node.js standard URL class before evaluating security lists. While this incurs a performance penalty compared to fast-uri, it guarantees perfect parity with downstream HTTP clients.

Second, you can implement a defensive regex pre-filter to block incoming parameters containing raw Unicode compatibility characters (specifically \u3002, \uFF0E, \uFF61) within scheme-relative formats. This ensures that any input resembling a domain name is restricted to standard ASCII alphanumeric and punctuation sets before hitting the parsing step.