GHSA-5QHF-9PHG-95M2: Stored Cross-Site Scripting via Parser Differential in Loofah allowed_uri?

The Ruby library Loofah is a critical component of the Rails security architecture, designed to orchestrate the parsing, manipulation, and sanitization of HTML and XML documents. It is built as an abstraction layer over Nokogiri, which provides fast XML parsing capabilities by wrapping Libxml2. In many Rails installations, Loofah is called transitively through the rails-html-sanitizer gem to protect applications from user-supplied payloads containing malicious scripts. The primary attack surface includes rich-text inputs, comments, profile bio fields, and any user-managed markdown or HTML blocks.

The vulnerability designated as GHSA-5QHF-9PHG-95M2 identifies a severe sanitization bypass within the allowed_uri? method of the Loofah::HTML5::Scrub module. This helper method is responsible for validating HTML attributes that store URIs, such as the href attribute of an anchor tag or the src attribute of an iframe. The function assesses whether the URI belongs to an allowed set of protocols, rejecting unsafe active scripting protocols such as javascript: or vbscript:.

By exploiting a parser differential, an attacker can manipulate numeric character references (NCRs) to bypass Loofah's scheme detection entirely. Specifically, when an attacker supplies a URI with a scheme separator or control characters represented as NCRs without trailing semicolons, the backend engine fails to decode them. Consequently, the backend treats the URI as a harmless relative link and allows it to pass. When modern, specification-compliant client browsers render the output, they aggressively decode the semicolon-less entities, reconstruct the malicious URI, and execute the active script context. This leads to Stored Cross-Site Scripting (XSS) within the application's domain.

The underlying security flaw resides in a structural parser differential between the backend Ruby standard library and the parsing engines built into modern web browsers. When evaluating attribute values, Loofah attempts to decode any encoded HTML entities so that it can evaluate the canonical string representation against its protocol blacklist. To perform this decoding, Loofah historically invoked CGI.unescapeHTML on the target attribute string prior to checking it against regex filters.

However, the Ruby standard library decoder CGI.unescapeHTML strictly adheres to classical XML/HTML specifications regarding the structure of Numeric Character References. Under these strict guidelines, any decimal or hexadecimal character reference must terminate with a trailing semicolon. For instance, a colon is written as : (decimal) or : (hexadecimal). If an entity is constructed without this terminating character, such as &#58 or &#x3a, CGI.unescapeHTML leaves the reference completely intact, failing to decode it.

Modern web browsers, by contrast, implement the error-tolerant HTML5 tokenization and parsing specifications. Under these specifications, the state machine for consuming numeric character references is highly permissive, resolving references that omit the trailing semicolon to maintain backwards compatibility with legacy web content. When a browser parses the attribute string javascript&#58alert(1), it consumes the characters &#58, recognizes it as a decimal representation of the colon character, decodes it, and executes the reconstructed javascript:alert(1) scheme.

This divergence in parsing logic also affects how control and whitespace characters are sanitized. If an attacker embeds a semicolon-less horizontal tab (&#9), line feed (&#10), or carriage return (&#13) within the protocol name (e.g., java&#9script:), the backend library fails to normalize or remove it. Since the backend regex looks for the literal string javascript:, the tab prevents a match. When the browser receives the markup, it resolves the tab, strips it from the protocol name as dictated by browser-side scheme validation rules, and executes the active payload.

To understand the precise vulnerability mechanics, we must review the execution flow of allowed_uri? in the affected versions. The vulnerable method is structured as follows:

# Affected implementation in Loofah < 2.25.2
def allowed_uri?(uri_string)
  # CGI.unescapeHTML fails to decode semicolon-less NCRs, leaving them unmodified
  uri_string = CGI.unescapeHTML(uri_string.gsub(CONTROL_CHARACTERS, ""))
  uri_string.gsub!(CONTROL_CHARACTERS, "")
  uri_string.gsub!(WHITESPACE_CHARACTER_REFERENCES, "")
  uri_string.gsub!("&colon;", ":")
 
  # The regex matches against the unescaped string. 
  # If the colon was encoded as &#58 (no semicolon), this match fails.
  return false if uri_string =~ URI_PROTOCOL_REGEX
  true
end

The validation fails because CGI.unescapeHTML processes javascript&#58alert(1) and returns it unchanged. The subsequent regular expression, URI_PROTOCOL_REGEX (defined as /Z[a-z][a-z0-9+\-.]*:/), expects a literal colon separator. Because no colon is present in the analyzed backend string, Loofah determines the URI is safe and allows it.

The official patch resolved this issue by implementing a custom decoding pipeline that intercepts and normalizes semicolon-less character references before standard checks are performed. The updated implementation introduces a dedicated helper method, decode_numeric_character_references, and modifies the validation pipeline:

# Patched implementation in Loofah v2.25.2
# The regex matches decimal or hex NCRs with an optional trailing semicolon
NUMERIC_CHARACTER_REFERENCE = /&#(x[0-9a-f]+|[0-9]+);?/i
 
# The URI protocol regex is updated to utilize the SafeList's defined protocol separator
URI_PROTOCOL_REGEX = /\A[a-z][a-z0-9+\-.]*#{SafeList::PROTOCOL_SEPARATOR}/
 
def allowed_uri?(uri_string)
  # The input is normalized through the custom decoder after CGI.unescapeHTML
  uri_string = decode_numeric_character_references(CGI.unescapeHTML(uri_string.gsub(CONTROL_CHARACTERS, "")))
  uri_string.gsub!(CONTROL_CHARACTERS, "")
  uri_string.gsub!(WHITESPACE_CHARACTER_REFERENCES, "")
  uri_string.gsub!(":", ":")
 
  # Normalized strings containing a decoded colon are now caught and blocked
  return false if uri_string =~ URI_PROTOCOL_REGEX
  true
end

To prevent secondary security issues, the maintainers engineered the decode_numeric_character_references helper with a critical defense-in-depth guard against Denial of Service (DoS) attacks. Because conversion of a string to an integer in Ruby via .to_i can be CPU-intensive if the string is arbitrarily long, an attacker could attempt to exhaust CPU cycles by supplying an entity with thousands of leading zeros (e.g., &#0000...0058). The patch mitigates this risk by filtering out leading zeros and verifying that the length of the significant digits corresponds to valid Unicode codepoint limits:

def decode_numeric_character_references(string)
  string.gsub(NUMERIC_CHARACTER_REFERENCE) do |reference|
    digits = ::Regexp.last_match(1)
    hexadecimal = digits.start_with?("x", "X")
    digits = digits[1..-1] if hexadecimal
    significant_digits = digits.sub(/\A0+/, "")
 
    # The maximum Unicode code point is U+10FFFF (6 hex or 7 decimal digits)
    # Any larger value is skipped to prevent unnecessary integer conversion
    next reference if significant_digits.length > (hexadecimal ? 6 : 7)
 
    codepoint = significant_digits.to_i(hexadecimal ? 16 : 10)
    begin
      codepoint.chr(Encoding::UTF_8)
    rescue RangeError
      # If the integer is out of bounds for UTF-8, return the original reference
      reference
    end
  end
end

Exploitation of GHSA-5QHF-9PHG-95M2 requires the target application to accept user-supplied HTML and sanitize it using a vulnerable version of Loofah prior to rendering it. No authentication or elevated privileges are required beyond the permission to submit input that is processed by the sanitizer.

An attacker can exploit the vulnerability using several payload configurations designed to leverage the browser's tolerant parsing rules. The most direct approach is replacing the protocol separator colon with a semicolon-less NCR:

<!-- Decimal representation of colon (&#58) without semicolon -->
<a href="javascript&#58alert(document.cookie)">Click to View Profile</a>
 
<!-- Hexadecimal representation of colon (&#x3a) without semicolon -->
<a href="javascript&#x3aalert(1)">Click to View Profile</a>

When Loofah processes these tags, the backend parser evaluates the attribute value as safe. Once written to the database and rendered on the victim's page, the browser decodes the entity, reconstructs the active URI scheme, and executes the JavaScript payload when the victim interacts with the link.

Beyond the protocol separator, attackers can also obfuscate the protocol name itself by inserting whitespace characters that are represented by semicolon-less NCRs. Because modern browsers strip control characters and whitespace from the scheme of a URI prior to evaluating its protocol, the following payload executes successfully:

<!-- Tab character (&#9) splits the protocol word -->
<a href="java&#9script:alert(1)">Verify Account Details</a>
 
<!-- Line Feed (&#10) splits the protocol word -->
<a href="java&#10script:alert(1)">Verify Account Details</a>

The backend parser evaluates the scheme as java&#9script, which does not match the blocklist. Upon rendering, the browser decodes &#9 to a raw tab, strips it from the protocol string, and treats the remaining URI as javascript:alert(1).

The security impact of a successful sanitization bypass leading to Stored Cross-Site Scripting (XSS) is severe. Because the malicious payload is stored permanently on the application server, every user who retrieves and renders the compromised resource becomes a victim of the attack. No further active exploitation steps are required from the attacker once the payload is injected.

An attacker exploiting this vulnerability can execute arbitrary JavaScript in the context of the victim's browser session. This enables several high-impact attack scenarios:

• Session Hijacking: The executed script can read sensitive browser storage, including non-HttpOnly cookies and localStorage keys, allowing the attacker to steal active session tokens and masquerade as the victim.
• Data Exfiltration: Malicious scripts can perform silent API requests to downstream application servers, exfiltrating private user data or performing state-modifying actions on behalf of the victim.
• Phishing & Defacement: The DOM can be manipulated to display fraudulent login prompts, capturing user credentials and redirecting users to attacker-controlled domains.

The severity is amplified in multi-tenant or collaborative platforms where user profiles, comments, or shared workspaces are accessed by multiple corporate accounts, potentially leading to widespread session compromise and lateral movement within the target enterprise.

The primary remediation for this vulnerability is upgrading the loofah dependency to version 2.25.2 or higher. This update introduces the robust decode_numeric_character_references helper, neutralizing the parser differential between the sanitizer and modern browsers. Applications using Bundler should execute bundle update loofah and verify the change in Gemfile.lock.

If upgrading immediately is not feasible, several defensive controls can be implemented to mitigate the risk of exploitation:

1. Implement a Strict Content Security Policy (CSP): A robust CSP is the most effective secondary defense against XSS. Enforcing policies that restrict script execution to trusted domains and ban inline scripts (unsafe-inline) prevents injected protocols from executing, even if they bypass backend filters:

   Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none';

2. Web Application Firewall (WAF) Rules: Configure edge-protection systems to detect and block incoming request parameters containing semicolon-less character references that decode to control characters or colons. Regular expressions can target structures like &#0*58 or &#x0*3[aA] when positioned inside potential URL attributes.

3. Sanitization Auditing: Conduct regular security reviews of all entry points accepting user-supplied markup. Ensure that sanitization is consistently applied on the backend before data storage and that downstream templates do not inadvertently disable escaping.