CVE-2026-86472 in fast-uri
Summary
by MITRE • 09/15/2026
fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv. In versions before 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4, fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference such as //host there is no scheme, so the host canonicalization that would normally repair this does not run, and parse, normalize, and equal then disagree on the same host. An application that makes a case-sensitive host decision on fast-uri output, for example a host allowlist or denylist that compares the parsed host or uses equal, can be steered past the check with a percent-encoded uppercase octet, and because hostnames are case-insensitive in DNS and HTTP the evading spelling still reaches the host the check meant to gate. The issue is fixed in fast-uri 2.4.7, 3.1.8, and 4.1.5, and users should upgrade to one of those versions or later. As a workaround, compare hosts case-insensitively by lowercasing the parsed host before any allowlist or denylist decision.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The fast-uri library serves as a critical dependency-free implementation of RFC 3986 for URI parsing within the Node.js ecosystem, underpinning major frameworks such as Fastify and validation tools like ajv. A significant security vulnerability exists in specific versions of this library, namely those before version 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4. This flaw stems from an incorrect ordering of operations during the canonicalization process for URIs containing scheme-relative references, such as those beginning with double slashes followed by a host identifier without an explicit protocol scheme. The core technical defect lies in the library's decision to fold the host component to lowercase before performing percent-decoding on that same host string. This sequence is fundamentally flawed because it fails to account for uppercase octets encoded within percent-encoding sequences, such as %41 which represents the character A.
When a URI contains a percent-encoded uppercase letter in the host portion of a scheme-relative reference, the library first converts any existing lowercase letters to their uppercase equivalents or vice versa depending on implementation specifics but critically fails to decode the percent-encoded characters before applying case normalization rules intended for literal text. Consequently, an encoded uppercase octet like %41 is decoded into a literal A after the folding operation has already occurred. Since the folding step does not process these newly revealed uppercase letters, they remain in their original case state rather than being normalized to lowercase as required by strict RFC 3986 compliance for host canonicalization. This discrepancy creates an inconsistency where different methods within the library behave differently regarding the same input; specifically, parse, normalize, and equal functions may disagree on whether two URIs are equivalent when one contains a percent-encoded uppercase character in the host field while another does not.
The operational impact of this vulnerability is severe for applications that rely on fast-uri output to make security-critical decisions based on hostname matching. Many web applications implement allowlists or denylists to control access, often comparing parsed hosts against known safe or malicious domains using case-sensitive string comparisons. Because the library fails to properly canonicalize percent-encoded uppercase characters in scheme-relative references, an attacker can craft a URI that bypasses these checks by encoding uppercase letters in the host portion of a URL. For instance, if an application blocks access to example.com but allows other hosts, an attacker could use //example%43om or similar variations where %41 represents A and potentially other encoded characters are used to mimic blocked domains while technically passing case-sensitive equality checks due to the library's bug.
This bypass is particularly dangerous because DNS resolution and HTTP protocols treat hostnames as case-insensitive by default. Therefore, even if an application successfully filters out a literal example.com from its allowlist, it will still route traffic intended for that domain when presented with //example%41com or similar variants containing encoded uppercase letters. The lack of scheme in scheme-relative references means the standard canonicalization logic that would normally repair case inconsistencies is not triggered, leaving the malformed host string to propagate through the application's security controls and reach the backend server. This effectively allows attackers to evade access control mechanisms designed to restrict traffic based on domain names, potentially leading to unauthorized data access or service disruption depending on what resources are gated by these checks.
To mitigate this risk, developers must upgrade fast-uri to version 2.4.7, 3.1.8, or 4.1.5 and later, where the parsing logic has been corrected to ensure percent-decoding occurs before case folding for host components in scheme-relative references. For applications unable to immediately update their dependencies, a robust workaround involves manually enforcing case-insensitive comparison of hosts derived from fast-uri outputs. This can be achieved by lowercasing the parsed host string prior to any allowlist or denylist evaluation logic within the application code. By ensuring that all hostname comparisons are performed in lowercase regardless of how they were encoded in the original URI, applications can neutralize this bypass technique and maintain consistent security postures aligned with DNS case-insensitivity principles.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation as it involves failing to correctly process input data according to specification requirements for canonicalization. It also relates to CWE-697 Incorrect Comparison During Canonicalization which specifically addresses errors in how inputs are normalized before comparison operations. In terms of attack vectors and tactics, this flaw facilitates evasion techniques categorized under ATT&CK T1048 Exfiltration Over Alternative Protocol or potentially T1592 Gather Victim Host Information if used for reconnaissance bypasses, although its primary utility here is circumventing access controls which maps to ATT&CK T1078 Valid Accounts in a broader sense of gaining unauthorized entry through logic flaws rather than credential theft. The root cause highlights the importance of adhering strictly to RFC standards during URI parsing implementations to prevent subtle logical errors that can be exploited for security bypasses.