CVE-2026-73491: 
Ruby vulnerability analysis and mitigation

CVE-2026-73491 is a security feature bypass vulnerability in Loofah, a Ruby library for manipulating and transforming HTML/XML documents built on Nokogiri. The flaw exists in Loofah::HTML5::Scrub.allowed_uri?, which fails to reject javascript: URIs whose scheme is split or prefixed with the HTML5 named whitespace character references 	 or 
. Affected versions are >= 2.25.0 and < 2.25.2; version 2.25.2 contains the fix. It was disclosed on July 15, 2026, 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 validation of unsafe equivalence in input (CWE-1289). allowed_uri? uses CGI.unescapeHTML to decode HTML entities before checking the URI scheme, but CGI.unescapeHTML handles numeric character references while leaving HTML5 named character references like 	 (U+0009) and 
 (U+000A) intact. As a result, a payload such as java	script:alert(1) passes the scheme check because the method does not recognize the obfuscated javascript: prefix — yet browsers decode and strip those whitespace characters per the WHATWG URL parser, ultimately executing javascript:alert(1). This is a bypass of the prior fix for GHSA-46fp-8f5p-pf2m, which addressed equivalent numeric character references but not the named forms. Critically, only direct callers of allowed_uri? with HTML-encoded strings are affected; Loofah's default sanitize() path is not vulnerable because Nokogiri decodes entities during DOM parsing before URI evaluation (GitHub Advisory, Fix Commit).

Successful exploitation enables cross-site scripting (XSS) in the context of end users' browsers. Applications that call Loofah::HTML5::Scrub.allowed_uri? directly to validate user-controlled URLs and then render the approved value into an href or other browser-interpreted URI attribute may inadvertently allow malicious javascript: URLs to execute arbitrary JavaScript. Higher-level features built on allowed_uri? — such as Action Text 8.2's markdown link validation — are also in scope. The impact is limited to integrity and confidentiality at the system/subsystem level (e.g., session hijacking, credential theft, or DOM manipulation), with no direct availability impact (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not automatable (per NVD SSVC assessment) and requires an attacker to have low-level privileges to submit a crafted URI that is then validated by the vulnerable code path. The EPSS score is approximately 0.245%, reflecting a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. It was responsibly reported by GitHub user @connorshea (GitHub Advisory).

1. Identify a vulnerable target: Find a Ruby application using Loofah versions 2.25.0 or 2.25.1 that calls Loofah::HTML5::Scrub.allowed_uri? directly with user-supplied, HTML-encoded URI strings (e.g., a link submission form, a markdown editor using Action Text 8.2).
2. Craft a bypass payload: Construct a javascript: URI with the scheme split by an HTML5 named whitespace character reference that CGI.unescapeHTML does not decode, such as java	script:alert(document.cookie) or 
javascript:alert(1).
3. Submit the payload: Submit the crafted URI through the application's input mechanism (e.g., a URL field in a form, a markdown link). The application passes the HTML-encoded string to allowed_uri?, which fails to detect the obfuscated scheme and returns true (safe).
4. Trigger execution: The approved URI is rendered into an href attribute or similar browser-interpreted attribute in the HTML output. When a victim user clicks the link, the browser decodes and strips the 	/
 references per the WHATWG URL parser, resolving the URL to javascript:alert(document.cookie) and executing the JavaScript payload in the victim's browser context (GitHub Advisory, Fix Commit).

• Logs: Application logs showing user-submitted URLs containing the strings 	, 
, 	, or 
 adjacent to javascript: or vbscript: scheme fragments in URI fields.
• Network: HTTP requests to the application containing URL parameters or form fields with encoded whitespace character references (	, 
) embedded within URI values.
• Application Behavior: Unexpected JavaScript execution reported by users after clicking links rendered by the application; browser console errors or alerts triggered from href attributes containing javascript: URIs.
• File System / Code Review: Presence of Loofah gem versions 2.25.0 or 2.25.1 in Gemfile.lock or gem installation directories on Ruby application servers.

Upgrade Loofah to version 2.25.2 or later, which explicitly strips 	 and 
 named character references before URI scheme evaluation (Loofah Release). If immediate patching is not possible, avoid passing HTML-encoded strings directly to Loofah::HTML5::Scrub.allowed_uri?; instead, rely on Loofah's default sanitize() method, which is not affected by this vulnerability. Additionally, review any custom URI validation logic that calls allowed_uri? directly and add supplementary validation to strip or reject 	 and 
 references before passing strings to the method (GitHub Advisory).

The vulnerability was responsibly disclosed by GitHub user @connorshea and patched by the Loofah maintainer (flavorjones/Mike Dalessio) on July 15, 2026, the same day the fix was merged (GitHub Advisory). The NixOS community tracked the issue for the rubyPackages.loofah package (NixOS/nixpkgs#552158), and Debian and Wolfi Linux distributions also registered the CVE for their package ecosystems (Feedly). No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified.