Track vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
6.5
Loofah fails to block malicious JavaScript URIs
published 3 months ago
Summary
Loofah's security feature can be bypassed by using numeric character references without semicolons in JavaScript URIs. This allows malicious scripts to be executed, even if Loofah is configured to block them. To stay safe, update to the latest version of Loofah and review your security settings.
What to do
- Update mike dalessio loofah to version 2.25.2.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| RubyGems | mike dalessio | loofah |
>= 2.25.0, < 2.25.2 Fix: upgrade to 2.25.2
|
Original advisory text
Loofah `allowed_uri?` does not detect `javascript:` URIs split by numeric character references without semicolons
## Summary
`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` or `vbscript:` URIs when the scheme is split by a numeric character reference that has no trailing semicolon. A browser decodes such references and resolves the URL to an executable `javascript:` scheme, while `allowed_uri?` reports it safe.
This is a bypass of the fix for [GHSA-46fp-8f5p-pf2m](https://github.com/flavorjones/loofah/security/advisories/GHSA-46fp-8f5p-pf2m), which handled numeric character references with a trailing `;` (`	`, ` `, ` `) but did not cover the forms without semicolons.
## Details
`allowed_uri?` decodes HTML entities with `CGI.unescapeHTML`, which decodes numeric character references only when they carry a trailing `;`. A reference without a semicolon such as `:` (colon) or `	` (tab) is left literal, so the scheme-detection check finds no scheme, and the method falls through to its scheme-less path and returns `true`.
A browser, however, decodes numeric character references even without a trailing semicolon. An encoded colon such as `:` becomes the `:` scheme separator, so `javascript:alert(1)` resolves to `javascript:alert(1)`. Encoded whitespace such as `	` (tab) is decoded and then stripped from the URL, rejoining the surrounding text, so `java	script:alert(1)` also resolves to `javascript:alert(1)`. In both cases the URL executes while `allowed_uri?` approved it as safe.
Note that Loofah's default `sanitize()` path is **not** affected, because Nokogiri decodes or entity-escapes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects callers of the public `allowed_uri?` string-level helper that pass it HTML-encoded strings.
## Impact
Callers that validate a user-controlled URL with `Loofah::HTML5::Scrub.allowed_uri?` and then render the approved value into an `href` or other browser-interpreted URI attribute may be vulnerable to cross-site scripting (XSS). This includes applications that call `allowed_uri?` directly, as well as higher-level features built on top of it, such as Action Text 8.2's markdown link validation.
## Mitigation
Upgrade to Loofah >= 2.25.2.
## Credit
Responsibly reported by GitHub user @MoonFuji.
`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` or `vbscript:` URIs when the scheme is split by a numeric character reference that has no trailing semicolon. A browser decodes such references and resolves the URL to an executable `javascript:` scheme, while `allowed_uri?` reports it safe.
This is a bypass of the fix for [GHSA-46fp-8f5p-pf2m](https://github.com/flavorjones/loofah/security/advisories/GHSA-46fp-8f5p-pf2m), which handled numeric character references with a trailing `;` (`	`, ` `, ` `) but did not cover the forms without semicolons.
## Details
`allowed_uri?` decodes HTML entities with `CGI.unescapeHTML`, which decodes numeric character references only when they carry a trailing `;`. A reference without a semicolon such as `:` (colon) or `	` (tab) is left literal, so the scheme-detection check finds no scheme, and the method falls through to its scheme-less path and returns `true`.
A browser, however, decodes numeric character references even without a trailing semicolon. An encoded colon such as `:` becomes the `:` scheme separator, so `javascript:alert(1)` resolves to `javascript:alert(1)`. Encoded whitespace such as `	` (tab) is decoded and then stripped from the URL, rejoining the surrounding text, so `java	script:alert(1)` also resolves to `javascript:alert(1)`. In both cases the URL executes while `allowed_uri?` approved it as safe.
Note that Loofah's default `sanitize()` path is **not** affected, because Nokogiri decodes or entity-escapes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects callers of the public `allowed_uri?` string-level helper that pass it HTML-encoded strings.
## Impact
Callers that validate a user-controlled URL with `Loofah::HTML5::Scrub.allowed_uri?` and then render the approved value into an `href` or other browser-interpreted URI attribute may be vulnerable to cross-site scripting (XSS). This includes applications that call `allowed_uri?` directly, as well as higher-level features built on top of it, such as Action Text 8.2's markdown link validation.
## Mitigation
Upgrade to Loofah >= 2.25.2.
## Credit
Responsibly reported by GitHub user @MoonFuji.
Internet-facing
60 days
Internal
At next upgrade
- Not known to be exploited
- Needs hands-on effort to exploit (estimated)
- Gives an attacker partial control (estimated)
Type
CWE-184Incomplete List of Disallowed Inputs
CWE-79Cross-site Scripting (XSS)
Timeline
Published21 Jul 2026
Updated21 Jul 2026
First seen21 Jul 2026
Sources
GHSA-5qhf-9phg-95m2 · OSV
Track software like this
Free during beta