Read the docs
TI-2026-67085 Aliases GHSA-5qhf-9phg-95m2

Loofah `allowed_uri?` does not detect `javascript:` URIs split by numeric character references without semicolons

Priority LOW 38CWE-184Published · Updated

Key facts

Attack vector
—
Privileges required
—
User interaction
—
Attack complexity
—
Impact type
Cross-site scripting
Confidentiality · integrity · availability
—
Fix status
Fixed

No CVSS vector from any source. Fix status from GitHub. Impact type from CWE-79.

Summary

## 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 `&#58` (colon) or `&#9` (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 `&#58` becomes the `:` scheme separator, so `javascript&#58alert(1)` resolves to `javascript:alert(1)`. Encoded whitespace such as `&#9` (tab) is decoded and then stripped from the URL, rejoining the surrounding text, so `java&#9script: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.

Why it matters now

Fix Fixed loofah (RubyGems): 2.25.2

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
—loofah (RubyGems)2.25.0 to before 2.25.22.25.2Patch availableGHSA-5qhf-9phg-95m2
  • loofah (RubyGems) Vendor— Affected 2.25.0 to before 2.25.2 Fixed in 2.25.2 Patch available GHSA-5qhf-9phg-95m2

Remediation

  • Fix · GHSA-5qhf-9phg-95m2 loofah (RubyGems) Fixed in 2.25.2 Advisory →

Timeline

  1. 2026-10-03 Threatist record created from GHSA-5qhf-9phg-95m2

References

Sources

This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences