Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-23T14:16:54.810Z",
  "pubdate": "2026-08-23T14:16:54.810Z",
  "executiveSummary": "Multiple HTML sanitization bypass vulnerabilities have been identified in justhtml prior to version 1.16.0. These vulnerabilities involve improper sanitization, allowing active and dangerous content such as script or style elements to bypass the sanitization mechanism.\nThe primary impact of these flaws is the potential execution of arbitrary script content, leading to cross-site scripting (XSS) in applications consuming the sanitized output.\nThe affected product is justhtml in versions before 1.16.0. The issues predominantly affect advanced usage scenarios rather than the default JustHTML(..., sanitize=True) configuration used for ordinary parsed HTML.\nRisk implications include compromised application integrity and unauthorized script execution within the context of a user session. Attackers require the ability to supply crafted inputs or leverage specific advanced programmatic patterns to exploit the weaknesses.\nSpecific exploitation vectors include mutating or reusing sanitization policy objects, supplying programmatic DOM input with mixed-case tag names, crafting programmatic doctype names, or utilizing custom policies that preserve SVG or MathML to bypass foreign-content checks.",
  "technicalDetails": "The vulnerabilities reside within the sanitization logic of justhtml before version 1.16.0, specifically impacting advanced usage patterns and programmatic interfaces.\nThe root causes span multiple distinct architectural components within the sanitization engine: policy object handling, DOM input parsing, doctype serialization, and foreign-content validation for SVG and MathML.\nFirst, mutating or reusing sanitization policy objects, including exported defaults, causes state pollution that weakens subsequent sanitization operations.\nSecond, programmatic DOM input passed to sanitize() or sanitize_dom() fails to properly normalize mixed-case tag names such as ScRiPt or StYlE, allowing malicious tags to evade blocklists.\nThird, crafted programmatic doctype names improperly serialize into active markup, introducing unintended active content.\nFourth, custom policies that preserve SVG or MathML fail foreign-content checks, enabling the inclusion of animation elements, presentation attributes containing external url(...) references, or DOM trees incorrectly mislabeled with namespace='html'.\nDuring an attack flow, an adversary leverages one of these advanced pathways to smuggle dangerous payloads past the sanitizer. For instance, by providing mixed-case tag names via programmatic DOM input or by exploiting mutated policy states, active script or style markup survives the sanitization pipeline.\nWhen the resulting markup is rendered by a downstream consumer, the surviving active content executes in the victim's browser context, resulting in cross-site scripting.\nThe vulnerable components include the sanitize() and sanitize_dom() functions, policy management mechanisms, and foreign-content validation routines in justhtml versions prior to 1.16.0.\nAuthentication and privilege requirements depend on the host application's architecture, but exploitation generally requires the ability to supply malicious programmatic inputs or manipulate policy objects."
}