justhtml EUVD-2026-64659

Exploitation requires an application that (1) uses justhtml's to_markdown() converter on attacker-influenced HTML and (2) renders the resulting Markdown back into HTML that is served to victims - the vulnerability is inert if the Markdown is never rendered as HTML. The specific triggering inputs are text nodes containing HTML-significant characters, most reliably entity-decoded text (e.g. &lt;script&gt;) or text inside RCDATA/RAWTEXT-parsed elements: <title>, <textarea>, <noscript>, and <plaintext>. Limiting factors: it does not affect the to_html() output path, it does not apply to real <script>/<style> DOM elements (dropped unless html_passthrough=True), and actual code execution depends on a victim viewing the rendered output in a browser rather than on the parse step alone.

The supplied CVSS 4.0 vector (9.3, AV:N/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H) rates this Critical, but that scoring appears aggressive for a stored/reflected XSS sanitizer bypass: real impact is confined to the browser context of a victim who renders the Markdown, exploitation realistically requires that downstream rendering (a form of user/system interaction), and availability impact (VA:H) is not well supported by the described behavior. EPSS is not provided in the input, and the CVE is not listed in CISA KEV, so there is no evidence of active exploitation - the elevated signal here is the existence of a published PoC, not in-the-wild use. This is a legitimate priority for any application that feeds untrusted HTML through justhtml's to_markdown() and then renders the result, but the blanket VC:H/VI:H/VA:H should be treated with caution; a more defensible assessment is a medium-severity XSS with scope change (see assessed vectors). No conflict exists on the attack vector (network is plausible), but the impact metrics are the point of divergence.

An attacker submits content such as <title>&lt;img src=x onerror=alert(1)&gt;</title> or entity-encoded markup to an application that stores it, parses it with justhtml, and publishes it via to_markdown(); the angle brackets survive unescaped, so when the Markdown is rendered to HTML the injected <img onerror> executes JavaScript in a victim's browser. A proof-of-concept demonstrating the general case (<p>&lt;img src=x onerror=alert(1)&gt;</p>) is published in the vendor advisory, lowering the bar to reproduce.