CVE-2026-75931: 
JavaScript vulnerability analysis and mitigation

CVE-2026-75931 is a host confusion vulnerability in fast-uri, a URI parser for Node.js, caused by inconsistent IDN (Internationalized Domain Name) canonicalization on scheme-relative references. The library canonicalizes a host to its ASCII form only when an explicit scheme is present; scheme-relative references (e.g., //host/) are returned with the host verbatim, causing parse, resolve, normalize, and equal to produce different host values for the same input. This mismatch enables host confusion and security policy bypass in applications that use fast-uri for host validation. Affected versions are 2.4.2–<2.4.5, 3.1.3–<3.1.6, and 4.0.1–<4.1.3. It carries a CVSS v3.1 base score of 7.5 (High) (Github Advisory, Fastify Advisory).

The root cause is classified as CWE-436 (Interpretation Conflict): fast-uri's resolve() function applies IDN canonicalization (converting Unicode hostnames to their ASCII/Punycode form) only when the input URI contains an explicit scheme (e.g., https://). When resolving a scheme-relative reference such as //münchen.de/path against a scheme-bearing base URI, resolve() emits the host verbatim without canonicalization, even though the effective scheme is derivable. Consequently, re-parsing the resolved URI yields a different (canonicalized) host than what resolve() returned, creating a discrepancy between the host used for policy evaluation and the actual destination host. This is described as an incomplete fix for the prior CVE-2026-13676, where IDN canonicalization was applied only to scheme-bearing forms (Fastify Advisory, Github Advisory).

An unauthenticated remote attacker can craft a scheme-relative URI containing a non-ASCII (IDN) hostname to bypass host-based security policies enforced by applications using fast-uri. The application validates one (verbatim) host representation but ultimately resolves and connects to a different (canonicalized) host, enabling unauthorized redirection, SSRF, open redirect, or allowlist bypass. The primary impact is on integrity (policy bypass and unauthorized routing); there is no direct confidentiality or availability impact from the vulnerability itself, though downstream consequences such as data exfiltration via SSRF are possible depending on application context (Github Advisory, Fastify Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.23% (14th percentile), indicating a low near-term exploitation probability (Github Advisory). The attack requires no authentication and no user interaction, and is automatable over the network, which lowers the barrier for exploitation if a PoC were to emerge.

1. Identify a target application: Find a Node.js application that uses a vulnerable version of fast-uri (2.4.2–<2.4.5, 3.1.3–<3.1.6, or 4.0.1–<4.1.3) to parse, validate, or route URIs based on host policy checks.
2. Craft a scheme-relative URI with an IDN hostname: Construct a URI using a scheme-relative reference format with a non-ASCII (internationalized) hostname, e.g., //münchen.de/sensitive-path or //аttасker.com/ (using Unicode lookalike characters).
3. Submit the crafted URI: Send the malicious URI to the target application's input (e.g., a redirect parameter, a URL validation endpoint, or a proxy/fetch target field).
4. Trigger the policy check: The application calls fast-uri's parse() or equal() on the scheme-relative reference, which returns the verbatim (non-canonicalized) host. The application evaluates this host against its allowlist/blocklist and may pass validation.
5. Achieve policy bypass: The application then calls resolve() to build the final URL. The resolved URI, when re-parsed, yields the canonicalized (ASCII/Punycode) host — a different value — causing the application to connect to an unvalidated destination, enabling SSRF, open redirect, or allowlist bypass (Fastify Advisory, Github Advisory).

• Logs: Application logs showing URI resolution to unexpected or external hosts not matching the originally validated host value; discrepancies between the host logged at validation time and the host logged at connection/request time.
• Network: Outbound HTTP/HTTPS requests from the Node.js application to unexpected external hosts, particularly those with internationalized domain names or Punycode equivalents (e.g., xn--mnchen-3ya.de for münchen.de); unusual SSRF-like traffic to internal network resources triggered by external input.
• Application Behavior: Redirect responses or proxy requests resolving to hosts not present in the configured allowlist; errors from fast-uri's resolve() related to non-ASCII host conversion in patched versions (indicating attempted exploitation against an upgraded instance).

Upgrade fast-uri to the patched versions: 2.4.5, 3.1.6, or 4.1.3, depending on the major version in use. These releases fix resolve() to canonicalize the host consistently once the effective scheme is known, and fail closed if a raw non-ASCII host cannot be converted. As a temporary workaround (if upgrading immediately is not possible), ensure that scheme-relative references are always resolved against a base URI that carries an explicit scheme before performing any host-policy or origin check. Additionally, review all host validation logic in applications using fast-uri to ensure it handles both scheme-relative and scheme-inclusive URI formats consistently (Fastify Advisory, Github Advisory).

The advisory was published by mcollina (a core Fastify maintainer) on August 23, 2026, with remediation review by UlisesGascon, and was reported by baeseungwon1010. The vulnerability was picked up by standard vulnerability tracking services including Tenable (Nessus plugin 339307), INCIBE-CERT, AUSCERT (ESB-2026.10308), and Red Hat (affecting hardened image RPMs), indicating moderate industry attention for a supply-chain library issue (Fastify Advisory).