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.