~ / search / GHSA-w74x-v6f9-j3xg

GHSA-w74x-v6f9-j3xg

fast-uri vulnerable to URI scheme spoofing via percent-encoded scheme decoding

Source: GitHub Advisory Database (reviewed) Moderate CVE-2026-110306

Packages

EcosystemPackageAffectedFixed in
npm fast-uri < 2.4.8 2.4.8
npm fast-uri >= 3.0.0, < 3.1.9 3.1.9
npm fast-uri >= 4.0.0, < 4.2.3 4.2.3

Details

As written in the advisory (Markdown source, shown as plain text).

### Impact `fast-uri` percent-decodes the scheme component with the legacy global `unescape()` before validating it, so an input whose decoded scheme is a valid but dangerous token is emitted as a live scheme. RFC 3986 section 3.1 does not allow percent-encoding in a scheme, so no RFC or WHATWG parser treats such input as having that scheme, but `fast-uri` does. For example, `normalize('%6Aavascript:alert(1)')` returns `javascript:alert(1)`, `resolve('https://a.example/', '%6Aavascript:alert(1)')` returns `javascript:alert(1)`, and `parse('%6Aavascript:alert(1)').scheme` returns `javascript`. The `%uXXXX` form (`%u006Aavascript:`) produces the same result, and `equal('%68ttp://a/', 'http://a/')` returns `true`. An application that screens dangerous schemes on the raw input and then stores or renders `normalize(input)` or `resolve(base, input)` turns an inert string into an executable `javascript:`, `data:`, or `vbscript:` URL, a stored or reflected cross-site scripting vector in the consuming application. `equal()` also treats an encoded and a plain scheme as the same, which can bypass equality-based allowlists. ### Patches Upgrade to `fast-uri` `2.4.8`, `3.1.9`, or `4.2.3`. ### Workarounds Reject input whose scheme part (before the first `:`, and before any `/`, `?`, or `#`) contains `%`. Alternatively, check `parse(x).scheme` against an allowlist after normalization and use that same parsed result rather than the raw string.

References

External links from the advisory. They lead to third-party sites.