Crass CVE-2026-116695

Exploitation requires that a downstream application parse attacker-supplied untrusted CSS with Crass (< 1.0.8) through a sanitizer that makes allow/deny decisions and then re-serializes the result without rejecting bad URL tokens - confirmed affected sanitizers are Sanitize through 7.0.0 (CSS.properties, style attributes, CSS.stylesheet, <style> elements), Loofah (scrub_css), and rails-html-sanitizer (sanitize_css, and sanitize when style is a permitted attribute). The attacker-controlled CSS must contain a bad URL token in which a ')' follows an escaped backslash so that Crass over-consumes and smuggles declarations, style rules, or at-rules such as @import. Limiting factors: there is no impact unless such a Crass-based sanitize-and-reserialize pipeline is in use; the CVSS UI:P reflects that a victim must render the sanitized output in a browser for impact to occur; and the ceiling on impact is CSS-only effects (UI redress/clickjacking, external resource loading, CSS-based data exfiltration) - it does NOT allow script execution in modern browsers. There is no practical workaround other than upgrading to Crass 1.0.8; the advisory notes that rejecting any CSS containing the '\' sequence would block the known trigger but is a blunt measure that may reject legitimate CSS.

This is a moderate, conditional risk rather than a drop-everything emergency. The CVSS 4.0 base is 5.3 (Medium) with vector AV:N/AC:L/AT:N/PR:N/UI:P and impact only on the subsequent system (SC:L/SI:L) - i.e., the browser that renders the sanitizer's output, not the Crass library or host itself. Crass by itself merely mis-tokenizes input (CWE-436, interpretation conflict); real impact only materializes when Crass sits inside a CSS sanitizer that makes allow/deny decisions and re-serializes untrusted CSS - the advisory confirms this for Sanitize (through 7.0.0), Loofah, and rails-html-sanitizer. The vendor-assigned decision label is 'this_month' (not act_now/emergency), which aligns with the medium severity. No EPSS score was provided and the CVE is not in CISA KEV, so there is no signal of active or widespread exploitation; absence of these is not itself evidence of safety but does argue against an imminent mass-exploitation scenario. No standalone public exploit code is referenced - only an advisory that confirms the smuggling technique works in Chromium against the named sanitizers, plus regression tests in the fix commit. The main caveat: the PR:N/AV:N metrics describe the ease of delivering malicious CSS, but actual exploitability hinges entirely on whether a downstream application parses-and-reserializes untrusted CSS through an affected sanitizer - a condition the raw CVSS score does not capture. The explicit ceiling on impact is important: this does NOT enable script execution in modern browsers.

An attacker submits untrusted content containing crafted CSS (for example a user-supplied style attribute, comment, or rich-text field) to a web application that uses a Crass-based sanitizer such as Sanitize, Loofah, or rails-html-sanitizer. Because Crass mis-tokenizes a bad URL whose escaped backslash is followed by ')', the sanitizer treats smuggled declarations, rules, or @import at-rules as part of an inert bad-URL token and passes them through on re-serialization; a victim who later views the page has their browser parse and apply that live CSS, enabling UI redress, loading of attacker-controlled external resources, or CSS-based data exfiltration. No weaponized public exploit is referenced, but the advisory confirms the bypass against the named sanitizers' output in Chromium.