CVE-2026-110180: fast-uri vulnerable to host confusion via unchecked WHATWG host canonicalization
fast-uri is a dependency-free RFC 3986 URI parser and serializer for Node.js. In versions from 2.4.2 through 2.4.7, from 3.1.3 through 3.1.8, and from 4.0.1 through 4.2.2, for HTTP-family schemes the canonicalizeHost() function passes the parsed host to the WHATWG URL parser and adopts its hostname without checking that the parser consumed the entire input as a host, so the authority can be silently rewritten: data before an at-sign is dropped and tab, carriage-return, and line-feed characters are stripped, with no error reported. An application that enforces host-based policy such as denylists, loopback filtering, redirect validation, or outbound proxy routing on one representation can then see the canonical host diverge from what it checked, allowing traffic to be steered to an unintended destination. The issue is fixed in fast-uri 2.4.8, 3.1.9, and 4.2.3, and users should upgrade to one of these versions or later. As a workaround, reject an authority that contains more than one at-sign or any tab, carriage-return, or line-feed before calling fast-uri, or treat any non-empty parse error as fatal and compare hosts only from the same parse result.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
fast-urito a version that resolves this vulnerability.Fixed in 4.2.3 - Compensating control
Before calling fast-uri, reject authorities containing more than one at-sign or any tab, carriage-return, or line-feed; alternatively, treat any non-empty parse error as fatal and compare hosts only from the same parse result.
Event History
Frequently Asked Questions
Which applications are realistically exposed to this issue?
Applications using an affected fast-uri release are exposed when they make security decisions based on a hostname, such as denylisting destinations, blocking loopback addresses, validating redirects, or selecting outbound proxy routes. The risk arises when the host checked by policy can differ from the host used after canonicalization.
What input is needed to trigger the host mismatch?
An attacker needs to supply a URI authority containing data before an at-sign, which can be dropped by WHATWG parsing, or containing tab, carriage-return, or line-feed characters, which can be stripped. The vulnerable canonicalization accepts these transformations without reporting an error.
How can this be mitigated before upgrading?
Reject any authority containing more than one at-sign or any tab, carriage-return, or line-feed before passing it to fast-uri. Alternatively, treat every non-empty parse error as fatal and ensure host comparisons use only values from the same parse result.
Which versions contain the fix?
Upgrade to fast-uri 2.4.8, 3.1.9, or 4.2.3, or to a later version in the applicable release line.