CVE-2026-4671
The CVE frames this as an 'application code supplies selectors' problem, but this framing obscures a fundamental design flaw in justhtml: the library treats selector matching and document processing as separable concerns when they're architecturally entangled in ways that expose DoS risk in normal usage patterns. When developers use justhtml to process scraped web content, render user-generated HTML, or build templating systems, they are running selector matching over attacker-controlled documents — regardless of where the selector strings originate. The 'sanitize=True' default addresses script injection, not resource exhaustion. It conflates content safety with algorithmic boundedness, a category error that pervades sanitize-first libraries. The DoS vectors described — deeply nested pseudo-classes, repeated positional matching, punctuation-heavy linkification — don't require attacker-controlled selectors. They're inputs available any time the library processes malformed or adversarial HTML. Justhtml offers no meaningful resource limits by default. A developer doing the sensible thing — processing arbitrary HTML with this library — gets no protection against oversized selectors, combinator chains, or cyclic DOM graphs. This is not an implementation bug that slipped through reasonable defaults. It's an availability failure baked into the library's design philosophy. The fix requires questioning whether a CSS selector engine operating on untrusted input should have O(n) or O(n²) worst-case behavior by default. Resource limits should be structural, not a boolean flag. The 'sanitize=True' default should be understood as 'we tried to block script injection,' not 'this library is safe to run on adversarial input.' If you're using justhtml to process untrusted HTML, treat the current version as lacking meaningful DoS protection regardless of sanitization settings. Monitor selector execution time aggressively, consider wrapping the library in a timeout sandbox, and evaluate whether the library's threat model aligns with your deployment context.
Reviewed through automated stages and approved by a human before publication.