Impact

fast-uri v3.1.1 and earlier decodes percent-encoded authority delimiters (%40 as @, %3A as :) inside the host component and serializes them back as raw characters. This changes the URI structure, turning a hostname into userinfo plus a different host.

For example, http://trusted.com%40evil.com/ normalizes to http://trusted.com@evil.com/, which reparses as host evil.com with userinfo trusted.com.

Applications that normalize untrusted URLs before host allowlist checks, redirect validation, or outbound request routing can be steered to a different authority than the original URL appeared to contain.

Patches

Upgrade to fast-uri >= 3.1.2.

Workarounds

None. Upgrade to the patched version.

Impact

fast-uri v3.1.0 and earlier decodes percent-encoded path separators (%2F) and dot segments (%2E) before applying dot-segment removal in normalize() and equal(). This makes encoded path data behave like real / and .., so distinct URIs collapse onto the same normalized path.

For example, http://example.com/public/%2e%2e/admin normalizes to http://example.com/admin, and equal() considers them the same URI.

Applications that normalize or compare attacker-controlled URLs to enforce path-based policy can be bypassed. A path that looks confined under an allowed prefix can normalize to a different location.

Patches

Upgrade to fast-uri >= 3.1.1.

Workarounds

None. Upgrade to the patched version.

Impact

fast-uri versions >= 2.3.1, <= 4.0.0 fail to canonicalize Unicode/IDN hostnames for HTTP-family URLs. The IDN conversion path calls URL.domainToASCII(...) on the global WHATWG URL constructor, where that helper does not exist. The resulting TypeError is silently routed into parsed.error, but parse(), normalize(), and equal() all return with the host left in its original Unicode form.

For example, http://127。0。0。1/ is treated by fast-uri as host 127。0。0。1, while Node's WHATWG URL parser and fetch() canonicalize the same input to 127.0.0.1.

Applications that use fast-uri to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination.

Patches

Upgrade to fast-uri v4.0.1, v3.1.3, or v2.4.2

Workarounds

None. Upgrade to the patched version.

fast-uri serializes the port component of a URI without validating it. When recomposing the authority, the userinfo and host components are escaped but the port is concatenated verbatim, so a port value that is not a sequence of digits can inject authority delimiters, demoting the intended host to userinfo and pointing the authority at an attacker-controlled host. Both fast-uri and Node's URL read the result back as the attacker's host with no error, so re-validating the built URI does not catch it. This affects applications that build URIs from parts and assign untrusted data to the port component through the serialize, normalize, or equal functions in their object forms. The issue affects fast-uri versions before 2.4.6, from 3.0.0 before 3.1.7, and from 4.0.0 before 4.1.4. It is fixed in 2.4.6, 3.1.7, and 4.1.4, where recomposeAuthority rejects any port that is not a digit sequence per RFC 3986.

fast-uri accepts a host that contains an unbalanced or misplaced authority bracket without reporting an error. A host that starts with an opening bracket but does not end with a closing bracket is neither validated as an IP literal nor canonicalized as a domain name, so parse() returns it as the host with error undefined, while Node's URL and the HTTP clients built on it resolve the same string to a different host. An application that reads the parsed host to make a host decision, such as an SSRF denylist, a redirect allowlist, or proxy routing, and then passes the original URL to an HTTP client evaluates its policy against a string that is not the host the request reaches. The same host is carried through normalize, equal, and resolve. This affects fast-uri versions 2.4.5, 3.1.6, and 4.1.3, and is fixed in 2.4.6, 3.1.7, and 4.1.4, where parse() reports a malformed host for any host that contains a bracket but is not a valid IPv6 literal.

Impact

fast-uri canonicalizes a host to its ASCII form only when the input carries an explicit scheme. When resolve() resolves a scheme-relative reference (//host/) against a scheme-bearing base, it still emits the host verbatim even though the effective scheme is known, so re-parsing the resolved URI yields a different host than the one resolve() returned. An application that resolves an untrusted reference with fast-uri and then checks or routes on the resulting host can make a policy decision on one host and reach another. This is an incomplete-fix variant of CVE-2026-13676, whose IDN canonicalization was applied only to the scheme-bearing form.

Patches

Upgrade to fast-uri 2.4.5, 3.1.6, or 4.1.3. resolve() now canonicalizes the host once the effective scheme is known, and fails closed if a raw non-ASCII host cannot be converted.

Workarounds

Resolve scheme-relative references against a base that carries a scheme before performing any host-policy or origin check.

Impact

fast-uri does not validate the complete RFC 3986 grammar for bracketed IPv6 literals, so a malformed literal with invalid trailing text is silently truncated to a different valid IPv6 address with no error reported. For example, normalize('http://[::not-valid]/private') returns http://[::]/private, and [fc00::not-hex] and [fe80::not-hex] collapse to [fc00::] and [fe80::]. An application that normalizes an untrusted URL before an outbound request, redirect, or host-policy check can be routed to a local or private address such as loopback (::1), unique-local, or link-local. Because parse().error is unset for these inputs, checking it does not protect the consumer.

Patches

Upgrade to fast-uri 2.4.5, 3.1.6, or 4.1.3. Malformed IPv6 literals are now rejected with a host error instead of being normalized to a valid address.

Workarounds

Reject untrusted URLs whose host is a bracketed IPv6 literal before passing them to fast-uri, or route outbound requests against an explicit allowlist of addresses rather than trusting the normalized host.

Impact

fast-uri decodes a hostname's percent escapes twice in a single normalize() or resolve() call: once during parsing and again during authority recomposition. A nested percent-encoded host therefore survives the first decode and is turned into a live destination by the second, so normalize('http://%256c%256f%2563%2561%256c%2568%256f%2573%2574/') returns http://localhost/. Applications that normalize or resolve an untrusted URI before an SSRF check, redirect validation, or host allowlist can be steered to a different destination, including internal addresses such as loopback or a cloud metadata endpoint, than the encoded input appeared to contain. This is an incomplete-fix variant of CVE-2026-6322, whose encoded-authority-delimiter fix introduced the second decode.

Patches

Fixed in fast-uri 2.4.5, 3.1.6, and 4.1.3.

Workarounds

Reject untrusted URIs whose host component contains an encoded percent sign (%25) before passing them to normalize() or resolve().

Impact

fast-uri decodes percent-encoded characters in the scheme component with the legacy global unescape() and serializes the result back as raw characters, without re-escaping it or validating it as a scheme. A scheme that decodes to characters outside the RFC 3986 scheme grammar can therefore introduce structure the original input did not contain.

For example, %2f%2fevil.example:/pwn parses with no authority (parse().host is undefined), but resolve() and normalize() return //evil.example:/pwn, which reparses with host evil.example. The %uXXXX form (%u002f%u002fevil.example:/pwn) produces the same result, and a scheme containing %0d%0a reaches the output as a raw CR LF.

Applications that normalize or resolve untrusted URLs before a redirect check, host allowlist, or outbound request decision, especially ones that treat a missing authority as same-origin, can be steered to an attacker-chosen authority, and a normalized URI placed in a response header can carry an injected CR LF.

Patches

Upgrade to fast-uri >= 4.1.3, or >= 3.1.6 in the v3.x release line, or >= 2.4.5 in the v2.x release line.

Workarounds

None. Upgrade to the patched version.

Impact

fast-uri v4.1.1 and earlier require a literal // to recognize a URI authority, so a reference that uses \\, /\, or \/ as the authority introducer (in place of //, after an optional scheme) is parsed with no authority: the sequence and everything after it fold into the path. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) instead treats \ as interchangeable with / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input.

For example, fast-uri resolves \\evil.com/path against base https://allowed.com/ to https://allowed.com/%5C%5Cevil.com/path (confined to the trusted host), while Node's WHATWG URL resolves the same reference to https://evil.com/path.

Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination.

Patches

Upgrade to fast-uri v4.1.2, v3.1.5, v2.4.4.

Workarounds

None. Upgrade to the patched version.

Impact

fast-uri v4.1.0 and earlier do not treat a literal backslash (U+005C) as an authority delimiter. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) normalizes \ to / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input string.

For example, http://evil.com\@allowed.com is treated by fast-uri as host allowed.com with userinfo evil.com\, while Node's WHATWG URL parser and fetch() see host evil.com with path /@allowed.com.

Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination, including cloud metadata endpoints, loopback, or internal hosts.

Patches

Upgrade to fast-uri v4.1.1, v3.1.4, or v2.4.3.

Workarounds

None. Upgrade to the patched version.