CVE-2026-110180: 
JavaScript vulnerability analysis and mitigation

CVE-2026-110180 is a URI host confusion vulnerability in the fast-uri Node.js package, classified as "Security policy bypass via improper host canonicalization." It affects versions 2.4.2–2.4.7, 3.1.3–3.1.8, and 4.0.1–4.2.2 of the dependency-free RFC 3986 URI parser and serializer. The vulnerability was published on October 20, 2026, with patches released the same day. It carries a CVSS v3.1 base score of 4.8 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause lies in the canonicalizeHost() function, which — for HTTP-family schemes (http, https, ws, wss, or any scheme with domainHost: true) — passes the parsed host to the WHATWG URL parser and adopts its .hostname output without verifying that the parser consumed the entire input string. This creates an interpretation conflict (CWE-436) rooted in improper input validation (CWE-20, CWE-1286): RFC 3986 permits @ inside the authority component, and the WHATWG parser silently drops everything before the last @ (treating it as userinfo) and strips TAB (\t), carriage-return (\r), and line-feed (\n) characters without raising an error. For example, http://a@b@evil.example/ is canonicalized to host evil.example, and a host containing embedded whitespace characters has those characters silently removed. The equal() and resolve() functions then operate on the rewritten host, creating a policy/use desync between what an application validated and what fast-uri returns (GitHub Advisory).

An unauthenticated remote attacker can craft a malicious URI that bypasses host-based access controls enforced by the application — including denylists, loopback filtering, open redirect validation, and outbound proxy routing — because the host the application checks differs from the host fast-uri ultimately resolves. This can result in traffic being silently steered to unintended destinations, enabling server-side request forgery (SSRF)-like scenarios, security control bypass, and potential exposure of internal services. The confidentiality and integrity impacts are rated Low, with no availability impact, reflecting the indirect nature of the bypass (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high attack complexity, as an attacker must craft a URI that passes application-level validation while causing fast-uri to rewrite the authority component — a condition that depends on the specific host-based policy logic of the target application (GitHub Advisory, Feedly).

1. Identify a target application: Find a Node.js application that uses a vulnerable version of fast-uri (2.4.2–2.4.7, 3.1.3–3.1.8, or 4.0.1–4.2.2) to enforce host-based security policies such as redirect validation, SSRF protection, or outbound proxy routing.
2. Craft a malicious URI with multiple at-signs: Construct a URI such as http://allowed-host@attacker.example/ or http://a@allowed-host@attacker.example/. The application's pre-validation logic may check the first or intermediate host segment, while fast-uri's canonicalizeHost() will resolve to attacker.example after WHATWG parsing drops everything before the last @.
3. Alternatively, embed whitespace characters: Craft a URI like http://attacker.example\t/ (with a literal TAB, CR, or LF in the host). The application may reject or flag the clean hostname but pass the whitespace-containing one, while fast-uri strips the whitespace and resolves to attacker.example.
4. Submit the crafted URI: Send the malicious URI to the target application endpoint (e.g., a redirect URL parameter, a webhook URL field, or a proxy destination input).
5. Achieve policy bypass: The application validates the URI against its denylist or allowlist using the raw or pre-parsed representation, passes validation, and then fast-uri's canonical host diverges — causing the application to route traffic to the attacker-controlled or otherwise restricted destination (GitHub Advisory).

• Network: Outbound HTTP/HTTPS requests from the application server to unexpected or internal hosts that should be blocked by policy; requests to loopback addresses (127.0.0.1, ::1) or internal RFC 1918 ranges originating from the application process.
• Logs: Application access logs showing URIs with multiple @ characters in the host/authority component (e.g., http://a@b@host/path); URIs containing URL-encoded or raw TAB (%09), CR (%0D), or LF (%0A) characters within the host portion.
• Application Behavior: Redirect responses or proxy requests being sent to destinations not matching the validated host; security policy checks passing for URIs that should have been blocked based on the canonical host.

Upgrade fast-uri to the patched versions: 2.4.8, 3.1.9, or 4.2.3 (or later within each major branch). For teams unable to upgrade immediately, two workarounds are available: (1) reject any URI authority containing more than one @ sign or any TAB, CR, or LF character before passing the URI to fast-uri; or (2) treat any non-empty parse(x).error result as fatal and compare hosts only from the same parse() call result, never mixing representations. Dependency scanning tools (e.g., npm audit) can be used to identify affected versions in the dependency tree (GitHub Advisory, Red Hat Bugzilla).

The advisory was published by mcollina (Matteo Collina, a core Node.js and Fastify maintainer) on the GitHub Security Advisory page, with UlisesGascon credited as remediation reviewer, indicating prompt handling within the Fastify project's security process. Red Hat tracked the issue via Bugzilla (Bug 2556008) and the OpenJS Foundation's CNA assigned the CVE, reflecting coordinated disclosure through established channels. No significant broader media coverage or notable social media discussion has been observed at this time (GitHub Advisory, Red Hat Bugzilla).