fast-uri vulnerable to host confusion via unchecked WHATWG host canonicalization

Impact

fast-uri versions >= 2.4.2, <= 2.4.7, >= 3.1.3, <= 3.1.8, and >= 4.0.1, <= 4.2.2 can silently rewrite the host of an HTTP-family URL (http, https, ws, wss, or any scheme with domainHost: true). For those schemes canonicalizeHost() passes the parsed host to the WHATWG URL parser and adopts its .hostname without checking that the parser read the whole input as a host. RFC 3986 permits @ inside the host group and the WHATWG parser strips TAB, LF, and CR, so the authority fast-uri reports is rewritten by that second parser with no error set: data before an @ is dropped and whitespace is removed.

For example, fast-uri parses http://a@[email protected]/ to host evil.example (dropping the b segment), and a host containing a raw TAB, CR, or LF has those characters stripped. equal() then treats a whitespace-smuggled host as the same as the clean one, and resolve() rewrites the authority the same way.

Applications that use fast-uri to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) on one representation, such as the raw input, see a policy/use desync: the canonical host fast-uri returns differs from what was checked, and traffic can be steered to an unintended destination.

Patches

Upgrade to fast-uri 2.4.8, 3.1.9, or 4.2.3.

Workarounds

Reject URIs whose authority contains more than one @, or contains TAB, CR, or LF, before calling fast-uri. Alternatively, treat any non-empty parse(x).error as fatal, and compare hosts only from the same parse() result.