GHSA-wjr9-j795-jxcr fast-uri vulnerable to host confusion via unchecked WHATWG host canonicalization

• npm fast-uri: >= 2.4.2, < 2.4.8 → fixed in 2.4.8 • npm fast-uri: >= 3.1.3, < 3.1.9 → fixed in 3.1.9 • npm fast-uri: >= 4.0.1, < 4.2.3 → fixed in 4.2.3

Impact `fast-uri` versions `>= 2.4.2, = 3.1.3, = 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.