Vulnerabilities

fast-uri, the OpenJSF/Fastify URI parsing library, fails to validate hosts that contain an unbalanced or misplaced bracket, so parse() returns the malformed string as the host with no error instead of validating it as an IP literal or canonicalizing it as a domain name. The flaw is triggered whenever an attacker-supplied URL with such a host is parsed: applications that read the parsed host to make a security decision — such as an SSRF denylist, redirect allowlist, or proxy routing rule — and then pass the original URL to Node's URL-based HTTP clients send the request to a different host than the one their policy actually checked. An attacker can exploit this discrepancy to bypass host-based controls and reach internal or otherwise restricted destinations (SSRF) or to slip past redirect and proxy restrictions; the malformed host is also carried through normalize, equal, and resolve. Any Node.js application or library using affected fast-uri versions (2.4.5, 3.1.6, 4.1.3 or earlier in those lines) where the parsed host drives network policy is affected. No public proof-of-concept or in-the-wild exploitation is known: EPSS is low at 0.2% and the issue is not in CISA KEV.

Do: Upgrade fast-uri to 2.4.6, 3.1.7, or 4.1.4 (matching your installed major version) and rebuild lockfiles; then audit code paths where fast-uri's parse() host output drives SSRF denylists, redirect allowlists, or proxy routing. As an interim mitigation, derive host decisions from the same URL parser the HTTP client uses (Node's URL) or reject hosts containing brackets that are not valid IPv6 literals.

fast-uri serializes the port component of a URI without validating it, so when the authority is recomposed a non-numeric port value containing characters such as '@' or ':' can inject authority delimiters into the string. Applications that build URIs from parts and assign untrusted data to the port component, then call serialize, normalize, or equal in their object forms, can have the intended host demoted to userinfo and the URI's authority silently repointed at an attacker-controlled host. Both fast-uri and Node's built-in URL parser read the recomposed URI back as the attacker's host without error, so re-validating the built URI does not catch the manipulation, enabling host-allowlist bypass, potential credential exposure via the userinfo component, and integrity-only attacks (CVSS 3.1 7.5, C:N/I:H/A:N). Anyone using fast-uri before 2.4.6, from 3.0.0 before 3.1.7, or from 4.0.0 before 4.1.4 who passes untrusted values into the port component is affected. There is no known public proof-of-concept, the issue is not in CISA's KEV catalog, and EPSS estimates only a 0.2% chance of exploitation within 30 days, so it is not currently known to be exploited in the wild.

Do: Upgrade fast-uri to 2.4.6 (2.x line), 3.1.7 (3.x line), or 4.1.4 (4.x line), where recomposeAuthority rejects any port that is not a digit sequence per RFC 3986; use 'npm ls fast-uri' or lockfile review to find which of your builds pull in vulnerable versions. Until patched, validate that any user-supplied port is purely numeric before assigning it to the port component, and review SSRF or host-allowlist logic that trusts URIs rebuilt from parts with fast-uri or Node's URL parser.

fast-uri is a URI parser for Node.js. During parsing it runs a legacy decoding pass over the scheme component and never re-escapes the result, and serialization writes the scheme back out verbatim, unlike the host component which is re-escaped. As a result an input whose scheme carries percent-encoded slashes parses as a scheme with no authority, so the parsed host and error are both undefined, yet resolving or normalizing that same input emits a network-path reference whose authority is attacker-chosen and re-parses to that host. An application that allowlists on the parsed host, or treats a reference with no authority as safe to resolve against its base, gets the opposite of what it checked, giving an off-site redirect, server-side request forgery, or address-policy bypass. The legacy decoder also expands non-standard escape forms, widening the issue past upstream filters, and control characters in the scheme can reach the output as raw carriage return and line feed. The affected versions are 2.3.1 up to but not including 2.4.5, 3.0.0 up to but not including 3.1.6, and 4.0.0 up to but not including 4.1.3. The issue is fixed in 2.4.5, 3.1.6, and 4.1.3, which reject a scheme that is not valid after decoding. Users should upgrade to a patched version.

fast-uri before 4.1.2, 3.1.5, and 2.4.4 requires a literal double forward slash to recognize a URI authority, so a reference that uses a backslash based introducer in place of it (backslash backslash, forward slash backslash, or backslash forward slash) is parsed with no authority and folds into the path. Node's native WHATWG URL parser instead treats a backslash as interchangeable with a forward slash for special schemes, so the two parsers extract different hosts from the same input. Applications that use fast-uri to enforce host based policy such as allowlists, SSRF filtering, or redirect validation before passing the same URL into Node's URL or fetch consumers can be steered to an unintended host. Upgrade to fast-uri 4.1.2, 3.1.5, or 2.4.4.

Impact: fast-uri versions from 2.3.1 through 4.1.0 (including the 3.x line up to 3.1.3 and the 2.x line up to 2.4.2) do not treat a literal backslash character (U+005C) as an authority delimiter. Node's native WHATWG URL parser, used by fetch, undici, and Node's http and https clients, normalizes the backslash to a forward slash for special schemes such as http, https, ws, wss, ftp, and file. As a result, the two parsers extract different hosts from the same input string. Applications that use fast-uri to enforce host-based policy such as allowlists, denylists, loopback or SSRF filtering, redirect validation, or outbound proxy routing before passing the same URL into Node's URL or fetch consumers can be steered to an unintended destination, including cloud metadata endpoints, loopback, or internal hosts. Patches: upgrade to fast-uri 4.1.1, 3.1.4, or 2.4.3. Workarounds: none.

Impact: In body-parser versions prior to 1.20.6 (1.x line) and 2.3.0 (2.x line), when the parser is configured with an invalid limit option value such as an unparseable string or NaN, bytes.parse returns null and the request body size check is silently skipped. Applications that rely on limit as their primary safeguard against oversized request bodies will accept arbitrarily large payloads, leading to excessive memory and CPU usage and denial of service. Patches: This issue is fixed in body-parser 1.20.6 and 2.3.0. After the fix, invalid limit values throw a clear error at parser construction time instead of silently disabling enforcement, while null and undefined continue to fall back to the default limit of 100kb. Workarounds: Validate the limit value before passing it to body-parser. For example, parse the value at startup and reject any configuration where the result is null or a non-finite number.

fast-uri versions 2.3.1 through 3.1.2 and 4.0.0 fail to canonicalize Unicode (IDN) hostnames for HTTP-family URLs. The IDN conversion path calls a helper that does not exist on the global URL constructor, silently leaving the host in its original Unicode form while normalize() and equal() still return values that differ from a WHATWG-compatible URL parser. Applications that use fast-uri to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) before passing the same URL to Node's URL or fetch can be bypassed when the two implementations resolve the same input to different hosts. Patches: upgrade to fast-uri 3.1.3 for the 3.x line or 4.0.1 for the 4.x line. Workarounds: enforce host policy using the same URL parser used for the actual request, or reject non-ASCII hosts before policy checks.