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

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.