RubySec

Providing security resources for the Ruby community

GHSA-p9wj-w8xq-vjx6 (loofah): Loofah allowed_uri? treats javascript: alert(1) as safe

Loofah allowed_uri? treats javascript: alert(1) as safe

Published: November 02, 2026

SECURITY IDENTIFIERS

GEM

loofah

UNAFFECTED VERSIONS

< 2.25.0

PATCHED VERSIONS

>= 2.25.3

DESCRIPTION

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&amp;#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 &amp;#x3a alert decodes as &amp;#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 &amp;#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.

RELATED