CVE-2026-86472: Hostname Canonicalization Bypass in fast-uri via Scheme-Relative URLs

The vulnerability CVE-2026-86472 is an improper handling of case sensitivity (CWE-178) within the fast-uri library, an RFC 3986 compliant URI parser written for Node.js environments. The library serves as a critical performance-oriented dependency for parsing tasks in popular web frameworks and validation engines, including Fastify and AJV. The attack surface is exposed primarily when downstream systems process, validate, or perform routing decisions on user-supplied URLs.

Because hostname matching and resolving are inherently case-insensitive, a vulnerability arises when parsing and security filtering do not normalize capitalization in an identical fashion. The flaw allows external actors to submit specifically formatted URIs that bypass standard string-matching list validations, while still resolving to targeted servers. This discrepancy can compromise validation barriers, potentially permitting unintended network exposure or unauthorized access paths.

The flaw is located within the canonicalization workflow of the parser function (parseWithStatus inside index.js), specifically during the handling of hostnames in scheme-relative URLs. RFC 3986 requires that registered names (hostnames) be case-insensitive and folded to lowercase. It also specifies that percent-encoded unreserved characters, such as %41 representing 'A', should be decoded to their literal equivalents.

In the vulnerable codebase, the host lowercasing fold was executed prior to the percent-decoding sequence. Consequently, the percent-encoding identifier %41 remained unchanged by the lowercasing pass since it does not contain uppercase alphabetical characters. When the subsequent percent-decoding step ran, it converted %41 into its literal ASCII representation 'A', leaving an uppercase character in the parsed hostname.

This parsed output is structurally invalid according to lowercase normalization requirements, yet resolves correctly at the DNS or network routing level. Furthermore, this canonicalization logic was conditionally executed only within scheme-specific validation blocks. When parsing a scheme-relative URI (e.g., //%41.com), the absence of a scheme bypassed the secondary normalization checks, preserving the casing inconsistency.

The vulnerable logic in index.js checks for a scheme handler before applying host percent-decoding and normalization. This design omitted scheme-relative URLs from consistent parsing:

if (!schemeHandler || (schemeHandler && !schemeHandler.skipNormalize)) {
  if (uri.indexOf('%') !== -1) {
    if (parsed.host !== undefined && !malformedIPLiteral) {
      const host = isIP ? parsed.host : normalizePercentEncoding(parsed.host, true)
      parsed.host = reescapeHostDelimiters(host, isIP)
    }
  }
}

The fix extracts the percent-decoding check outside of the scheme handler validation block, executing it unconditionally. The normalization process was also reordered to ensure case folding occurs after decoding:

if (uri.indexOf('%') !== -1 && parsed.host !== undefined && !malformedIPLiteral) {
  let host = isIP ? parsed.host : normalizePercentEncoding(parsed.host, true)
  if (!isIP) {
    // Fold reg-name case after decoding unreserved octets.
    host = normalizePercentEncoding(host.toLowerCase())
  }
  parsed.host = reescapeHostDelimiters(host, isIP)
}

This ensures that any percent-encoded unreserved characters are first decoded to their literal forms, then folded to lowercase, and finally normalized to restore valid percent-escapes.

Exploitation requires that an application parses an input URI, validates the parsed host against an allowlist or denylist using case-sensitive operations, and subsequently uses the original or parsed URL to make an HTTP request. The attacker crafts a scheme-relative URI containing percent-encoded uppercase letters matching characters in a restricted domain.

When the application evaluates A.com against a case-sensitive blocklist containing a.com, the match fails, allowing the request to proceed. The downstream HTTP client then performs case-insensitive resolution, routing the request to a.com anyway.

The primary risk associated with this vulnerability is the evasion of domain-based access controls, leading to security filter bypasses such as Server-Side Request Forgery (SSRF). If an application restricts outbound connections using an allowlist parsed by fast-uri, an attacker can bypass this protection to access internal endpoints.

This vulnerability has a CVSS v3.1 base score of 4.8 (Medium), reflecting high attack complexity and low impact on confidentiality and integrity. No active exploitation has been observed, and the exploit status remains at proof-of-concept level.

Remediation requires upgrading fast-uri to version 2.4.7, 3.1.8, or 4.1.5, depending on the active branch. These versions contain the refactored parsing logic that resolves the order-of-operations conflict.

Where immediate upgrades are not feasible, developers must manually fold parsed hostnames to lowercase before performing string validation. This mitigation prevents differential interpretations between the application's business logic and the network layer.