Where
-Infinity
0
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

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.

First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
SSRF
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
7

fast-uri normalize() decoded percent-encoded authority delimiters inside the host component and then re-emitted them as raw delimiters during serialization. A host that combined an allowed domain, an encoded at-sign, and a different domain was re-emitted with the at-sign as a raw userinfo separator, changing the URI's authority to the second domain. Applications that normalize untrusted URLs before host allowlist checks, redirect validation, or outbound request routing can be steered to a different authority than the input appeared to specify. Versions <= 3.1.1 are affected. Update to 3.1.2 or later.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203