CVE-2026-8445 in justhtml
Summary
by MITRE • 08/23/2026
justhtml versions <= 1.11.0 (fixed in 1.12.0) do not sufficiently escape HTML-significant characters (angle brackets) in text nodes when converting a parsed document to Markdown via to_markdown(). While a small set of Markdown metacharacters are escaped, characters such as < and > are preserved, so untrusted input that is safe in to_html() — including entity-decoded text (e.g. <script>) or text from RCDATA/RAWTEXT-parsed elements like <title>, <textarea>, <noscript>, and <plaintext> — can be emitted as raw HTML in the Markdown output, enabling a sanitizer bypass and potential cross-site scripting when that output is rendered.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/23/2026
The vulnerability identified in justhtml versions 1.11.0 and earlier represents a critical input validation failure within the library's document serialization logic, specifically affecting the conversion of parsed HTML documents to Markdown format via the to_markdown() method. This flaw stems from an insufficient escaping mechanism for HTML-significant characters, most notably angle brackets less than and greater than signs which are preserved in their raw form rather than being escaped or neutralized during the transformation process. While the library correctly handles a limited set of standard Markdown metacharacters such as asterisks and hashes it fails to apply equivalent rigor to characters that retain semantic meaning in HTML contexts when embedded within text nodes. This inconsistency creates a significant security gap where content deemed safe for direct rendering via the to_html() method can become dangerous when passed through the markdown conversion pipeline, particularly because the resulting Markdown output may contain raw HTML tags if not properly sanitized by downstream consumers.
The technical root cause lies in how justhtml handles entity-decoded text and specific element types during serialization. When a document is parsed entities such as <script> are decoded into their literal character equivalents less than script greater than for internal representation. In the to_html() method these characters are appropriately escaped back or handled safely ensuring no executable code is emitted. However in the to_markdown() implementation this decoding step leaves angle brackets exposed without subsequent escaping because Markdown syntax does not inherently require them to be escaped unless they form part of a recognized tag structure that might interfere with parsing rules. Consequently text from elements classified as RCDATA or RAWTEXT such as title textarea noscript and plaintext which are designed to contain raw character data rather than markup can inadvertently introduce unescaped angle brackets into the final Markdown string. This behavior effectively allows an attacker who controls input content to inject HTML tags directly into the output stream bypassing any assumptions that Markdown conversion provides a sanitization layer.
The operational impact of this vulnerability is severe as it enables potential cross-site scripting attacks in applications that rely on justhtml for converting user-generated or untrusted HTML content into Markdown format before further processing or display. If an application accepts malicious input containing encoded script tags and converts them to Markdown using the vulnerable version of justhtml those tags will appear verbatim in the output. When this Markdown is subsequently rendered by a parser that supports inline HTML such as many common JavaScript-based markdown renderers like marked or showdown the embedded script elements will execute within the context of the victim's browser session. This bypasses typical Content Security Policies and sanitization layers because the attack vector exploits the trusted conversion tool itself rather than targeting the final renderer directly making it difficult to detect using standard input validation rules that assume Markdown output is inherently safe from HTML injection.
From a classification perspective this vulnerability aligns with CWE-79 which describes improper neutralization of input during web page generation commonly known as cross-site scripting and specifically relates to CWE-83 where incorrect conversion between different character encodings or data formats leads to security weaknesses such as the failure to escape special characters appropriately. In terms of adversary tactics it maps to ATT&CK technique T1059 which covers command and script interpretation indicating that an attacker could leverage this flaw to execute arbitrary scripts within a victim's environment by manipulating how content is serialized across different markup languages. The severity is heightened because many web applications use markdown conversion as part of their sanitization strategy assuming it strips out dangerous HTML elements thereby creating a false sense of security for developers who do not implement additional output encoding or strict allow-listing policies on the final rendered view.
Mitigation strategies must address both immediate remediation and long-term architectural defenses. The primary solution is to upgrade justhtml to version 1.12.0 or later where this escaping logic has been corrected to ensure that angle brackets in text nodes are properly escaped during markdown conversion preventing raw HTML injection. For applications unable to immediately update dependencies implementing a secondary sanitization layer using a robust library such as DOMPurify on the output of to_markdown() before it is rendered can provide effective protection against residual risks. Additionally developers should avoid relying solely on format conversion for security and instead enforce strict Content Security Policies that restrict script execution origins and utilize context-aware encoding when displaying user content regardless of its intermediate format representation ensuring that even if a vulnerability exists in one stage of the pipeline it does not result in successful exploitation at the presentation layer.