Summary
Crass: Incorrect tokenization of bad URLs enables CSS sanitizer bypass
Crass's tokenizer didn't terminate a bad URL token at a ) that followed an escaped backslash (\\). As a result, Crass consumed more input as part of the bad URL than a spec-compliant browser does. CSS sanitizers that parse untrusted CSS with Crass and re-emit it could be tricked into passing through declarations, style rules, or at-rules (including @import) that the sanitizer would otherwise have removed, but that a browser would then parse and apply.
Details
While consuming the remnants of a bad URL (CSS Syntax Level 3, §4.3.15), Crass checked whether the previously consumed code point and the next code point formed a valid escape, in addition to checking the next two unconsumed code points. After an escaped backslash, the previously consumed code point is a backslash, so a following ) was incorrectly treated as escaped and the bad URL token continued until the next unescaped ) or the end of the input.
Browsers terminate the bad URL at that ), so everything Crass treated as part of the bad URL is live CSS to a browser.
This bug has existed in every released version of Crass.
Workarounds
There are no practical workarounds other than upgrading. Rejecting any CSS input that contains the character sequence \\ would block the known trigger, but this is a blunt measure and may reject legitimate CSS.
References
- CSS Syntax Module Level 3, "Consume the remnants of a bad url": https://drafts.csswg.org/css-syntax-3/#consume-remnants-of-bad-url
Impact
Crass by itself only mis-tokenizes input. The security impact is on CSS sanitizers that use Crass to make allow/deny decisions and then re-serialize the CSS. Exploitation requires a sanitizer that doesn't reject bad URL tokens wherever they occur. Confirmed examples (verified in Chromium against the sanitizers' output):
- Sanitize (all versions through 7.0.0):
- In
Sanitize::CSS.propertiesandstyleattributes, a bad URL inside a[...]or(...)block in the value of an allowlisted property can smuggle arbitrary declarations, such asposition: fixedor abackground-imageURL with a disallowed protocol. - In
Sanitize::CSS.stylesheetand<style>elements, a bad URL in a selector can smuggle arbitrary style rules and at-rules, including@import.
- In
- Loofah (
Loofah::HTML5::Scrub.scrub_css, used forstyleattributes), and therefore rails-html-sanitizer (sanitize_css, andsanitizewhenstyleis a permitted attribute): a bad URL inside an allowlisted function such ascalc()orrgb()can smuggle declarations Loofah normally strips, such asposition: fixedandurl()values.
Smuggled CSS can be used for UI redress (clickjacking or phishing overlays), loading attacker-controlled external resources, and, where rules or @import can be smuggled, CSS-based data exfiltration. This vulnerability doesn't allow script execution in modern browsers.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in Crass 1.0.8. Users of Sanitize, Loofah, rails-html-sanitizer, or any other library that uses Crass to sanitize CSS should upgrade Crass to 1.0.8 or later.
Frequently Asked Questions
- What is CVE-2026-116695? CVE-2026-116695 is a medium-severity security vulnerability in crass (rubygems), affecting versions <= 1.0.7. It is fixed in 1.0.8.
- Which versions of crass are affected by CVE-2026-116695? crass (rubygems) versions <= 1.0.7 is affected.
- Is there a fix for CVE-2026-116695? Yes. CVE-2026-116695 is fixed in 1.0.8. Upgrade to this version or later.
- Is CVE-2026-116695 exploitable, and should I be worried? Whether CVE-2026-116695 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-116695 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-116695? Upgrade
crassto 1.0.8 or later.