CVE-2026-126206 — loofah
Fix: flavorjones/loofah#324CVE-2026-126206 is a security vulnerability in loofah. A fix is available for loofah — see the affected versions and patch details below.
Loofah allowed_uri? treats data:text/html as safe text/plain
Real-World Exposure
loofahReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Loofah::HTML5::Scrub.allowed_uri? returns true for a data: URI whose mediatype is written with the HTML5 named character reference / in place of the solidus. Loofah reads that mediatype as malformed and falls back to the allowed text/plain, while a browser decodes the reference and reads the same URI as text/html.
Details
allowed_uri? decodes HTML entities with CGI.unescapeHTML, which handles numeric character references but not HTML5 named character references. / therefore survives normalization, so the mediatype carries no /, fails the MIME grammar, and falls back to the allowed text/plain under the WHATWG rule for a malformed mediatype.
:, /, 	 and 
 are the only named character references in the HTML5 table that decode to characters that change how a URI parses (U+003A, U+002F, U+0009 and U+000A; there is no named reference for U+000D), so this closes the set.
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 @ngpestelos.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | loofah | ≥ 2.25.2&&< 2.25.3 | 2.25.3bundle update loofah --conservative |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for loofah, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update loofah to 2.25.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-126206 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is evaluated as Moderate rather than Important because successful exploitation requires user interaction and is restricted to cases where applications explicitly invoke standalone URI validation routines on unparsed input. In typical deployments, standard HTML sanitization workflows decode entities…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.Source: Red Hat security advisory for CVE-2026-126206 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-126206 in your dependencies?
Find it across RubyGems, including transitive dependencies.