fast-uri CVE-2026-18446

Exploitation requires the target application to use fast-uri as an intermediate URL parsing and policy enforcement component - specifically for host allowlisting, SSRF filtering, or redirect validation - and then pass the same URL string to Node.js's native URL API or the fetch() function for actual HTTP consumption. The bypass applies exclusively to URI schemes designated 'special' under the WHATWG URL standard (http, https, ftp, ws, wss), because Node only treats backslash as a slash equivalent for these schemes; custom or non-special schemes are not affected. The attacker triggers the discrepancy by using a backslash-based authority introducer in the submitted URL (backslash-backslash '\\\\', forward slash-backslash '/\', or backslash-forward slash '\/') in place of the standard '//'. Limiting factors: applications that do not perform host-based policy enforcement via fast-uri are not exposed; applications that use only Node's native URL for both validation and consumption eliminate the parser differential; non-special URI schemes bypass the mechanism. Authentication at the application layer is not a limiting factor - PR:N in the CVSS vector confirms no credentials are required to submit a crafted URL to the validator.

The CVSS 7.5 High vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) accurately characterizes the ease of exploitation once a vulnerable application pattern is identified: no authentication, no elevated complexity beyond crafting a backslash URL, and high integrity impact from bypassing security controls. However, real-world risk is conditional - exploitation requires the target application to use fast-uri specifically as a security enforcement layer before delegating URL consumption to Node's URL or fetch API. Applications using fast-uri purely for parsing without security gating are not directly at risk. EPSS data was not provided in the source intelligence, so probabilistic exploitation likelihood cannot be quantified numerically. The vulnerability is not listed in CISA KEV and no public exploit code has been identified at time of analysis, suggesting active exploitation is not yet widespread. Despite the PR:N/AC:L ease of triggering the bypass, the full impact chain (SSRF, redirect hijack, allowlist bypass) requires the downstream application to act on the attacker-supplied URL - a common but not universal pattern. Teams using Fastify with host allowlisting or SSRF mitigations built on fast-uri should treat this as high priority; all others should apply the patch opportunistically in their next release cycle.

An attacker targeting an application that validates redirect destinations against an allowlist submits the URL 'http:\\\ internal-service.local/admin' as the redirect parameter. fast-uri parses the input, finds no recognizable authority (the backslash introducer is not treated as '//'), and the host-based allowlist check passes without blocking the request. Node's fetch API then processes the identical string, correctly extracts 'internal-service.local' as the host per WHATWG rules, and issues the HTTP request to the unintended internal endpoint. No public exploit code is known at time of analysis, but the technique is mechanically straightforward for any attacker familiar with URL parser differential research.