CVE-2026-7808 in justhtml
Summary
by MITRE • 08/23/2026
justhtml before 1.16.0 contains multiple HTML sanitization bypass issues that can allow active/dangerous content (e.g., script or style) to survive sanitization, potentially leading to cross-site scripting. The issues primarily affect advanced usage rather than the default JustHTML(..., sanitize=True) path for ordinary parsed HTML: mutating or reusing sanitization policy objects (including exported defaults) could weaken later sanitization; programmatic DOM input to sanitize()/sanitize_dom() could miss mixed-case tag names (e.g., ScRiPt, StYlE); crafted programmatic doctype names could serialize into active markup; and custom policies preserving SVG or MathML could allow animation elements, presentation attributes with external url(...) references, or DOM trees mislabeled as namespace="html" to bypass foreign-content checks. Fixed in 1.16.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/23/2026
The vulnerability identified in justhtml versions prior to 1.16.0 represents a critical failure in the library's HTML sanitization logic, specifically affecting scenarios involving advanced configuration and programmatic DOM manipulation rather than standard default usage patterns. This flaw allows active or dangerous content, such as JavaScript scripts and CSS stylesheets, to bypass security filters and persist within sanitized output. The core issue stems from inconsistencies between how different input methods are processed by the sanitizer engine. When developers utilize custom sanitization policies that preserve specific namespaces like SVG or MathML, the library fails to adequately enforce foreign-content checks. This oversight permits animation elements and presentation attributes containing external url references to remain in the final HTML structure. Furthermore, DOM trees explicitly mislabeled with a namespace attribute set to html can trick the sanitizer into treating them as safe native content rather than potentially malicious foreign markup, thereby creating an avenue for cross-site scripting attacks where attackers inject executable code that executes within the victim's browser context under the trust of the originating domain.
A significant portion of this vulnerability landscape involves state management and object mutation flaws inherent in how sanitization policies are handled during runtime. The library’s default path, which invokes sanitize with the standard True flag for ordinary parsed HTML, remains largely secure against these specific bypass techniques. However, when advanced usage patterns are employed, such as mutating or reusing existing sanitization policy objects including exported defaults, the integrity of subsequent sanitization operations is compromised. This mutable state allows an attacker to manipulate the configuration in a way that weakens the filtering rules applied later in the request lifecycle. By altering the policy object after its initial creation but before it is fully utilized for final output generation, malicious actors can effectively disable or bypass specific restrictions designed to block dangerous tags and attributes. This behavior violates the principle of least privilege by allowing dynamic reconfiguration of security controls without proper validation of the resulting state's safety implications.
Additionally, the vulnerability extends into the handling of programmatic DOM inputs passed directly to sanitize_dom functions. In these cases, the sanitizer exhibits a case-sensitivity flaw where mixed-case tag names such as ScRiPt or StYlE are not correctly identified and stripped. Standard HTML parsers often normalize tag names to lowercase before processing, but this implementation fails to apply that normalization consistently across all code paths. Consequently, attackers can craft payloads using varied capitalization schemes to evade regex-based or token-based detection mechanisms embedded within the sanitizer. This bypass technique is particularly dangerous because it targets edge cases in parsing logic rather than fundamental architectural flaws, making it difficult for automated security scanners to detect without deep static analysis of the source code behavior under specific input conditions.
The impact of these vulnerabilities is severe when applications rely on justhtml to sanitize user-supplied HTML content before rendering it back to users or storing it in a database. Successful exploitation leads directly to cross-site scripting, which can result in session hijacking, credential theft, defacement of web pages, and the distribution of malware through injected scripts. The risk is amplified by the fact that these bypasses require specific conditions related to policy reuse or programmatic input, meaning they may not be triggered by simple form submissions but could be exploited via complex API endpoints or internal application logic that constructs DOM trees programmatically before sanitization. This makes traditional web application firewalls less effective as they typically inspect raw HTTP payloads rather than the state of in-memory objects after library processing has occurred.
To mitigate these risks, organizations must immediately upgrade to justhtml version 1.16.0 or later where these specific bypass vectors have been addressed by enforcing stricter namespace validation and ensuring consistent case normalization for all tag names regardless of input method. For environments unable to patch immediately, it is crucial to avoid reusing sanitization policy objects across multiple requests or operations. Instead, policies should be instantiated fresh for each distinct sanitization task to prevent state mutation attacks. Developers should also audit any custom configurations that enable SVG or MathML support and ensure that foreign-content checks are rigorously applied even when these namespaces are permitted. Implementing a Content Security Policy header with strict script-src directives can provide an additional layer of defense by restricting the sources from which scripts can be loaded, thereby mitigating the impact if a bypass is successfully executed. Regular security assessments focusing on HTML sanitization logic and input validation practices should be conducted to identify similar weaknesses in other components of the application stack.