{"id":"CVE-2026-116695","aliases":["GHSA-pq4g-8rxf-4g29"],"url":"https://o3.security/vulnerability/CVE-2026-116695","summary":"Crass: Incorrect tokenization of bad URLs enables CSS sanitizer bypass","details":"## Summary\n\nCrass'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.\n\n## Details\n\nWhile 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.\n\nBrowsers terminate the bad URL at that `)`, so everything Crass treated as part of the bad URL is live CSS to a browser.\n\nThis bug has existed in every released version of Crass.\n\n## Impact\n\nCrass 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):\n\n- **Sanitize** (all versions through 7.0.0):\n - In `Sanitize::CSS.properties` and `style` attributes, a bad URL inside a `[...]` or `(...)` block in the value of an allowlisted property can smuggle arbitrary declarations, such as `position: fixed` or a `background-image` URL with a disallowed protocol.\n - In `Sanitize::CSS.stylesheet` and `