CVE-2026-126209

## Summary `Loofah::HTML5::Scrub.allowed_uri?` returns `true` for a `javascript:` or `vbscript:` URI whose scheme is split by a numeric character reference without a trailing semicolon, followed by a character that `allowed_uri?` strips, such as a space or tab. A browser ends the reference at that character and reads `javascript&#x3a alert(1)` as `javascript: alert(1)`. ## Details `allowed_uri?` strips control characters and whitespace before it decodes numeric character references. Removing the character that ends a semicolon-less reference lets the reference run on into the following text, so `&#x3a alert` decodes as `&#x3aa` (U+03AA) instead of a colon, and no scheme is detected. The same applies to decimal references and to references that encode a scheme letter, as in `&#x6a\tavascript:alert(1)`. Loofah's default `sanitize()` path is **not** affected, because Nokogiri decodes the entity during parsing before Loofah evaluates the URI. This issue affects only callers of the public `allowed_uri?` string-level helper that pass it HTML-encoded strings. ## Impact Applications that validate a user-controlled URL with `Loofah::HTML5::Scrub.allowed_uri?` and then render the approved value into an `href` or another browser-interpreted URI attribute may be vulnerable to cross-site scripting. `Rails::HTML::Sanitizer.allowed_uri?` re-exports the same helper. ## Mitigation Upgrade to Loofah >= 2.25.3. ## Credit Responsibly reported by GitHub user @manus-pi.