GHSA-5qhf-9phg-95m2
Fix: flavorjones/loofah@f1be9d8GHSA-5qhf-9phg-95m2 is a Cross-site Scripting (XSS) vulnerability in loofah. O3 Security confirms whether GHSA-5qhf-9phg-95m2 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Loofah `allowed_uri?` does not detect `javascript:` URIs split by numeric character references without semicolons
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-5qhf-9phg-95m2.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
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? 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, 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | loofah | ≥ 2.25.0&&< 2.25.2 | 2.25.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for loofah. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update loofah to 2.25.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5qhf-9phg-95m2 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-5qhf-9phg-95m2 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-5qhf-9phg-95m2. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5qhf-9phg-95m2 in your dependencies?
O3 detects GHSA-5qhf-9phg-95m2 across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.