CVE-2026-73492: flavorjones loofah · Cross-site Scripting
Affects flavorjones loofahSource CVE Database V5
Not known to be exploited · CVSS 2.3 Low : upgrade to 2.25.2 when convenient.
Data as of 10 Nov 2026, 23:24 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 33% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 2.25.2
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 12 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 10 Nov 2026.
What to do
Upgrade flavorjones loofah to 2.25.2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| flavorjonesloofah | Affected
| Fixed in
|
RubyGemsloofahpkg:gem/loofahOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Upgrade to loofah version 2.25.2 or later, where this issue is fixed. If upgrading is not immediately possible, avoid passing HTML-encoded strings directly to Loofah::HTML5::Scrub.allowed_uri?. The default sanitize() method remains safe and can be used as a mitigation.
Description
Loofah is a general library for manipulating and transforming HTML/XML documents and fragments, built on top of Nokogiri. From 2.25.0 until 2.25.2, Loofah::HTML5::Scrub.allowed_uri? does not reject javascript: or vbscript: URIs whose scheme is split by semicolon-less numeric character references such as :, 	, 
, or 
. CGI.unescapeHTML leaves these references encoded, so allowed_uri? reports the URL safe even though a browser decodes an encoded colon or strips encoded whitespace and executes the resulting URI scheme. This issue affects only callers that pass HTML-encoded strings directly to allowed_uri?; Loofah's default sanitize() path is not affected. This issue is fixed in version 2.25.2.
References
- github.com/flavorjones/loofah/security/advisories/GHSA-5qhf-9phg-95m2 (opens in a new tab)
- github.com/flavorjones/loofah/pull/308 (opens in a new tab)
- github.com/flavorjones/loofah/commit/f1be9d893b5a8dd79240441a912d8897e74c38c0 (opens in a new tab)
- github.com/flavorjones/loofah/releases/tag/v2.25.2 (opens in a new tab)