CVE-2026-73492: 
Ruby vulnerability analysis and mitigation

CVE-2026-73492 is a Cross-Site Scripting (XSS) vulnerability in the Loofah Ruby gem's allowed_uri? function, caused by incomplete rejection of javascript: and vbscript: URIs obfuscated with semicolon-less numeric character references (e.g., &#58, &#9, &#10, &#13). It affects Loofah versions >= 2.25.0 and < 2.25.2, and was disclosed on July 15, 2026, with a fix released the same day. The vulnerability was responsibly reported by GitHub user @MoonFuji and has a CVSS v4.0 base score of 2.3 (Low) (GitHub Advisory, Feedly).

The root cause is an incomplete list of disallowed inputs (CWE-184) combined with improper neutralization of equivalent special elements (CWE-76), leading to XSS (CWE-79). Loofah::HTML5::Scrub.allowed_uri? uses CGI.unescapeHTML to decode HTML entities before checking the URI scheme, but CGI.unescapeHTML only decodes numeric character references that carry a trailing semicolon. References without semicolons — such as &#58 (colon) or &#9 (tab) — are left encoded, so the scheme-detection regex finds no recognized scheme and returns true (safe). Browsers, however, decode these semicolon-less references and either resolve the encoded colon as a scheme separator (e.g., javascript&#58alert(1) → javascript:alert(1)) or strip encoded whitespace to rejoin a split scheme (e.g., java&#9script:alert(1) → javascript:alert(1)). This is a bypass of the prior fix for GHSA-46fp-8f5p-pf2m, which addressed semicolon-terminated references but not the semicolon-less variants. The vulnerability only affects callers that pass HTML-encoded strings directly to allowed_uri?; Loofah's default sanitize() path is unaffected because Nokogiri decodes entities during DOM parsing before URI evaluation (GitHub Advisory, Fix Commit).

Successful exploitation allows an attacker to inject javascript: or vbscript: URIs into href or other browser-interpreted URI attributes that are validated by allowed_uri?, resulting in XSS execution in the victim's browser when the link is clicked. Applications directly calling allowed_uri? with user-controlled, HTML-encoded input — including higher-level features such as Action Text 8.2's markdown link validation — are at risk of permitting malicious script execution. The impact is limited to client-side script execution in the context of the affected web application; there is no direct server-side compromise (GitHub Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Feedly). The NVD SSVC assessment classifies exploitation as "none" and the vulnerability as non-automatable. The EPSS score is approximately 0.245%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to supply a crafted HTML-encoded URI to an application that directly calls allowed_uri?, limiting the attack surface to specific usage patterns (GitHub Advisory).

1. Identify target application: Find a Ruby web application using Loofah >= 2.25.0 and < 2.25.2 that directly calls Loofah::HTML5::Scrub.allowed_uri? with user-supplied, HTML-encoded input (e.g., a link submission form, markdown editor with link validation, or Action Text 8.2 markdown link handling).
2. Craft obfuscated URI: Construct a javascript: URI where the colon is replaced with a semicolon-less numeric character reference, such as javascript&#58alert(document.cookie) (decimal) or javascript&#x3aalert(document.cookie) (hexadecimal without semicolon). Alternatively, split the scheme with an encoded whitespace character: java&#9script:alert(document.cookie).
3. Submit payload: Submit the crafted URI as a link value through the application's input mechanism (e.g., a form field, API endpoint, or markdown content).
4. Bypass validation: The application passes the HTML-encoded string to allowed_uri?, which calls CGI.unescapeHTML — leaving the semicolon-less reference encoded — and finds no recognized URI scheme, returning true (safe).
5. Trigger XSS: The approved URI is rendered into an href or similar attribute in the HTML output. When a victim user clicks the link, the browser decodes the numeric character reference and executes javascript:alert(document.cookie), achieving XSS in the victim's browser session (GitHub Advisory, Fix Commit).

• Network: HTTP requests containing URI values with patterns like javascript&#58, javascript&#x3a, java&#9script:, java&#10script:, or java&#13script: in link or href parameters submitted to the application.
• Logs: Application or web server access logs showing user-submitted content containing &#58, &#9, &#10, or &#13 adjacent to the string javascript or vbscript in URI fields.
• Application Behavior: Rendered HTML pages containing href attributes with obfuscated javascript: or vbscript: URI schemes (e.g., href="javascript&#58alert(1)") that were not sanitized by Loofah.

Upgrade Loofah to version 2.25.2 or later, which decodes semicolon-less numeric character references before scheme validation in allowed_uri? (Loofah Release). If immediate upgrade is not possible, avoid passing HTML-encoded strings directly to Loofah::HTML5::Scrub.allowed_uri?; instead, rely on Loofah's default sanitize() path, which is not affected by this vulnerability (GitHub Advisory). Applications using Action Text 8.2's markdown link validation should also prioritize upgrading, as that feature is built on top of allowed_uri?.

The vulnerability was responsibly disclosed by GitHub user @MoonFuji and addressed by the Loofah maintainer (flavorjones/Mike Dalessio) on the same day as disclosure, July 15, 2026, with a coordinated patch release (GitHub Advisory). The NixOS/nixpkgs project opened a tracking issue (NixOS/nixpkgs#552158) to update the rubyPackages.loofah package to address this and related security issues in versions below 2.25.2 (Loofah PR #308). No significant broader media coverage or notable community controversy has been observed.