CVE-2026-4671 in justhtml
Summary
by MITRE • 08/23/2026
justhtml before 1.18.0 contains multiple low-severity denial-of-service issues in CSS selector handling and linkification. Applications that evaluate attacker-controlled selector strings (via query(), matches(), or selector-based transforms), run selector matching over very large untrusted documents, construct DOM trees from untrusted structure, or enable linkification over attacker-controlled text may consume disproportionate CPU or memory. Triggers include oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes, repeated token/positional matching, cyclic DOM graphs causing non-terminating traversal, and punctuation-heavy or trailing-bracket linkification input. These are availability-only concerns and do not by themselves allow script execution, data disclosure, or sanitizer bypass. Default JustHTML(sanitize=True) usage is not expected to be exposed, since selectors are normally supplied by application code.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/23/2026
The vulnerability identified in justhtml versions prior to 1.18.0 represents a class of denial-of-service issues rooted in the inefficient handling of CSS selector matching and text linkification processes. As a specialized HTML sanitization library, justhtml is designed to parse and clean untrusted HTML input by applying specific rules and selectors defined by the application developer. However, when this library evaluates attacker-controlled or poorly validated selector strings through methods such as query(), matches(), or various selector-based transforms, it becomes susceptible to resource exhaustion attacks. The core technical flaw lies in the underlying algorithms used for matching CSS selectors against Document Object Model trees and processing text for automatic link creation. These operations do not implement sufficient bounds checking or complexity limits on the input data, allowing malicious actors to craft inputs that trigger disproportionate consumption of central processing unit cycles and memory resources. This behavior classifies as a resource exhaustion vulnerability where the system's availability is compromised without necessarily affecting its integrity or confidentiality directly through code execution.
From a technical perspective, several specific patterns within CSS selector handling can be exploited to induce these denial-of-service conditions. Oversized selectors that contain an excessive number of attributes or classes force the matching engine into lengthy comparison operations against every node in the DOM tree. Similarly, large lists of selectors require sequential evaluation across potentially millions of nodes, leading to linear or worse-than-linear time complexity relative to document size and selector count. Compound selectors with oversized components further exacerbate this issue by increasing the computational load for each individual match attempt. Deeply nested functional pseudo-classes introduce recursive overhead that can quickly spiral out of control as the parser attempts to resolve complex logical conditions within deeply structured HTML documents. Additionally, long combinator chains require extensive traversal and state management during matching, while repeated token or positional matching forces redundant computations across large datasets. These factors combine to create scenarios where a relatively small input string can cause significant performance degradation or complete system hang depending on the scale of the target document being processed.
Beyond selector handling, the linkification feature presents another vector for denial-of-service attacks when enabled over attacker-controlled text inputs. Linkification involves scanning plain text strings to identify and convert potential URLs into clickable anchor elements. When this process is applied to punctuation-heavy or trailing-bracket heavy input, it can trigger inefficient regular expression backtracking or excessive string manipulation operations. The parser may attempt numerous permutations of valid URL structures against malformed but syntactically plausible inputs, leading to high CPU utilization. This specific aspect highlights how even simple text processing features within security libraries can become attack surfaces if they lack safeguards against pathological input patterns designed to exploit algorithmic inefficiencies rather than logical flaws in the sanitization logic itself.
The operational impact of these vulnerabilities is strictly limited to availability concerns. Unlike cross-site scripting or data injection attacks, these issues do not allow for arbitrary script execution, direct data disclosure, or bypassing of existing security sanitizers. The primary consequence is that applications relying on justhtml may experience service interruptions due to resource exhaustion. In web server environments, this could manifest as slow response times, increased latency, or complete unresponsiveness under load from malicious requests. For batch processing systems handling large volumes of HTML content, the vulnerability can lead to prolonged job completion times and potential memory overflow errors if garbage collection cannot keep pace with allocation rates caused by pathological inputs. This makes the issue particularly relevant for high-throughput applications where performance stability is critical, even though it does not compromise the fundamental security posture regarding data integrity or confidentiality.
Industry standards provide useful frameworks for understanding and mitigating these risks. The vulnerabilities align closely with CWE-400, which covers uncontrolled resource consumption, specifically focusing on scenarios where input validation fails to limit computational complexity. Furthermore, from an adversary perspective, this behavior corresponds to ATT&CK technique T1496, Resource Hijacking, wherein attackers leverage system resources for denial of service rather than traditional exploitation methods like privilege escalation or data theft. Recognizing these patterns helps security teams categorize the threat correctly and prioritize remediation efforts based on availability requirements rather than assuming a lack of exploitability due to the absence of code execution capabilities.
Mitigation strategies should focus primarily on upgrading to justhtml version 1.18.0 or later, where these specific inefficiencies have been addressed through algorithmic improvements and input constraints. For applications unable to upgrade immediately, defensive coding practices are essential. Developers must ensure that selector strings passed to query(), matches(), or similar functions originate from trusted application code rather than user-supplied data. If dynamic selectors are necessary, they should be validated against a whitelist of allowed patterns before being processed by the library. Additionally, when enabling linkification over untrusted text inputs, it is advisable to implement length limits on input strings and consider using timeout mechanisms for processing operations to prevent indefinite hangs. Monitoring system metrics such as CPU usage and memory consumption during HTML parsing can also help detect anomalous behavior indicative of these denial-of-service attempts in real-time environments.
It is important to note that default configurations with sanitize=True are generally not exposed to this risk because selectors are typically hardcoded by developers rather than derived from external inputs. However, any customization or dynamic generation of selector rules introduces potential exposure if proper validation controls are not enforced at the application layer. Security architects should review all instances where justhtml is configured with user-influenced parameters and apply strict input sanitization principles to prevent abuse of its parsing capabilities. By treating these low-severity availability issues as part of a broader defense-in-depth strategy, organizations can maintain robust service continuity even in the face of sophisticated denial-of-service attempts targeting library-level inefficiencies.