Two fast-uri Vulnerabilities Allow URI Host Confusion and Authority Injection

What happened

Two separate advisories were published for fast-uri. CVE-2026-84292 (GHSA-qw65-cvwx-89v3) affects the serialize(), normalize(), and equal() functions: fast-uri escapes the userinfo and host components when rebuilding a URI's authority, but concatenates the port value verbatim without validating it. A port value such as '@127.0.0.1:8124' can inject authority delimiters, turning the intended host into userinfo and pointing the resulting URI at an attacker-controlled host. CVE-2026-84394 (GHSA-58mr-gqgx-xq4g) affects parse(), normalize(), equal(), and resolve(): fast-uri accepts a host containing an unbalanced or misplaced bracket ('[' or ']') without raising an error, even though such a host is not a valid IP literal or domain name. In one documented example, a host like '[@127.0.0.1' is returned by fast-uri's parse() with no error, while Node's URL (and HTTP clients built on it, such as http.get, axios, and got) resolve the same string to 127.0.0.1.

Technical cause

In CVE-2026-84292, the root cause is that fast-uri's authority-recomposition logic does not validate the 'port' field against the RFC 3986 grammar, which requires a port to consist only of digits. Any non-digit value is still appended to the output string as-is, allowing it to contain characters like '@' and ':' that have special meaning in a URI authority. In CVE-2026-84394, fast-uri's host-parsing logic does not detect or reject hosts with unbalanced or misplaced brackets, so a malformed IP-literal-like string passes through as a 'valid' host with no error flag set, even though it is not a well-formed IPv6 literal and not a legitimate domain name.

Why it matters

Both vulnerabilities create a discrepancy between what fast-uri reports as a URI's host and what an actual HTTP client will connect to. Applications that build URIs from separate parts (for example, combining a trusted host from configuration with a port from user input or a service record) or that use fast-uri's parse() output to enforce an SSRF denylist, a redirect allowlist, or proxy routing decisions can be bypassed: fast-uri reports one host, but the request is actually sent to a different, attacker-chosen host. Critically, re-validating the resulting URI string with fast-uri does not catch the problem, because fast-uri itself reads the crafted string back as the attacker's host without error.

Who is affected

Applications using fast-uri are affected if they construct URI components programmatically and pass untrusted data into the 'port' field before calling serialize(), normalize(), or equal() (CVE-2026-84292), or if they rely on fast-uri's parse(), normalize(), equal(), or resolve() output to make host-based security decisions before handing the original URL to an HTTP client (CVE-2026-84394). A 'port' value produced by fast-uri's own parse() function is always digits-only and is not affected by CVE-2026-84292. For CVE-2026-84394, clients that fail closed on credential-bearing URLs, such as Node's global fetch(), are stated not to be affected by the reported vector.

Affected versions

CVE-2026-84292 (authority injection via port): fast-uri versions from 4.0.0 up to but not including 4.1.4 are confirmed affected. The advisory also lists fixed versions 2.4.6 and 3.1.7 for earlier release lines, indicating corresponding vulnerable ranges existed in the 2.x and 3.x series. CVE-2026-84394 (host confusion via unclosed bracket): fast-uri version 4.1.3 is confirmed affected, with fixed versions 2.4.6, 3.1.7, and 4.1.4 listed, indicating corresponding issues in the 2.x and 3.x lines as well, with versions 2.4.5 and 3.1.6 specifically named as affected in the earlier series.

Fixes and mitigation

Both vulnerabilities are patched in fast-uri 4.1.4, 3.1.7, and 2.4.6. For CVE-2026-84292, the fixed recomposeAuthority logic now rejects any port value that is not composed solely of digits, per RFC 3986. For CVE-2026-84394, parse() now reports a malformed-host error for any host containing a bracket that does not form a valid IPv6 literal. If upgrading is not immediately possible: for the port issue, validate that the port value matches digits only (e.g., a pattern like ^\d*$) before passing a component to serialize(), normalize(), or equal(), and reject anything else. For the bracket issue, reject any URL whose host contains a '[' or ']' that is not a well-formed IPv6 literal before making a host-based decision.

Recommended action

Upgrade fast-uri to 4.1.4, 3.1.7, or 2.4.6 depending on your current release line. If immediate upgrading is not possible, apply the documented workarounds: validate port values as digits-only before serialization, and reject hosts containing unbalanced or misplaced brackets before using parsed host values for security decisions such as SSRF denylists or redirect allowlists.