CVE-2026-7808: justhtml before 1.16.0 Multiple Security Issues via Sanitization
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()/sanitizedom() 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
justhtmlto a version that resolves this vulnerability.Fixed in 1.16.0
Event History
Frequently Asked Questions
Who is most likely to be exposed to these bypasses?
Applications using advanced justhtml sanitization patterns are primarily affected, including those that mutate or reuse policy objects, pass programmatically constructed DOMs to sanitize() or sanitize_dom(), or use custom policies that preserve SVG or MathML. The ordinary JustHTML(..., sanitize=True) path for parsed HTML is not identified as the primary affected usage.
What input or configuration conditions can enable exploitation?
Relevant conditions include mixed-case dangerous tags in programmatic DOM input, crafted programmatic doctype names, and custom SVG or MathML policies that permit animation elements, presentation attributes containing external url(...) references, or trees labeled namespace="html". Reusing or modifying sanitization policies, including exported default policies, can also weaken subsequent sanitization.
What should teams do if they cannot immediately upgrade?
Avoid mutating or reusing sanitization policy objects, including exported defaults. Avoid sanitizing programmatically built DOMs with untrusted mixed-case tag names or crafted doctypes, and do not preserve SVG or MathML through custom policies unless the associated foreign-content handling is reviewed.
How can an application determine whether it is affected?
Review whether it uses a version before 1.16.0 and whether it relies on the advanced patterns described: policy mutation or reuse, sanitize()/sanitize_dom() with programmatic DOM input, crafted doctypes, or custom SVG/MathML-preserving policies. Applications limited to ordinary parsed HTML through JustHTML(..., sanitize=True) are not described as the primary affected path.