fast-uri CVE-2026-110306

Exploitation requires a consuming application that (1) uses fast-uri to parse/normalize/resolve a URL, (2) screens for dangerous schemes against the RAW input string, and then (3) stores or renders the normalized/resolved output (or relies on fast-uri's equal() for allowlist comparison). The concrete trigger is an input whose scheme component contains a percent sign that decodes to javascript, data, or vbscript. Limiting factors: the victim must render or click the resulting URL (UI:R), so it is not fully automatic; applications that validate the parsed/normalized scheme against an allowlist (rather than the raw string), or that reject any scheme containing '%', are not affected; and the flaw is inert in library usage that never emits the normalized scheme into an HTML/URL sink.

This is a genuine but moderate-priority web-security issue rather than a critical infrastructure flaw. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1, Medium) is internally consistent with a cross-site scripting outcome: network reachable, low complexity, no privileges, but requiring user interaction (victim must render/click the malicious URL), with a scope change (the injected script executes in the victim's browser, a different component) and only Low confidentiality/integrity impact and no availability impact. CWE-172 (Encoding Error) accurately captures the root cause - percent-decoding the scheme via legacy unescape() before validation. No EPSS score, CISA KEV listing, POC reference, or SSVC decision data was provided in the input, so exploitation status is: no public exploit identified at time of analysis. Critically, this is a LIBRARY defect whose real-world impact is fully conditional on consuming-application behavior (screening raw input, then trusting the normalized/resolved output) - the library alone is not directly exploitable, which tempers the raw CVSS-derived risk. Treat as a dependency-hygiene patch priority, not an emergency, absent evidence of a vulnerable usage pattern in your own code.

An attacker submits a URL whose scheme is percent-encoded (e.g. the decoded form resolves to "javascript") to an application that blocklists dangerous schemes on the raw string but then stores or renders the fast-uri-normalized/resolved result. Because the raw input does not visually match a dangerous scheme, it passes the filter, but normalization emits a live javascript:, data:, or vbscript: URL; when a victim later views or clicks it (UI:R), script executes in their browser as stored or reflected XSS. No public exploit code was identified in the provided intelligence.