Summary
JustHTML is vulnerable to XSS via code fence breakout in <pre> content
to_markdown() is vulnerable when serializing attacker-controlled <pre> content. The <pre> handler emits a fixed three-backtick fenced code block, but writes decoded text content into that fence without choosing a delimiter longer than any backtick run inside the content.
An attacker can place backticks and HTML-like text inside a sanitized <pre> element so that the generated Markdown closes the fence early and leaves raw HTML outside the code block. When that Markdown is rendered by a CommonMark/GFM-style renderer that allows raw HTML, the HTML executes.
This is a bypass of the v1.12.0 Markdown hardening. That fix escaped HTML-significant characters for regular text nodes, but <pre> uses a separate serialization path and does not apply the same protection.
Details
The vulnerable <pre> Markdown path:
- extracts decoded text from the
<pre>subtree - opens a fenced block with a fixed delimiter of ``````
- writes the decoded text directly into the output
- closes with another fixed ``````
Because the fence length is fixed, attacker-controlled content containing a backtick run of length 3 or more can terminate the code block. If the content also contains decoded HTML-like text such as <img ...>, that text appears outside the fence in the resulting Markdown and is treated as raw HTML by downstream Markdown renderers.
The issue is not that HTML-like text appears inside code blocks. The issue is that the serializer allows attacker-controlled <pre> text to break out of the fixed fence.
Reproduction
from justhtml import JustHTML
payload = "<pre>```\n<img src=x onerror=alert(1)></pre>"
doc = JustHTML(payload, fragment=True) # default sanitize=True
print(doc.to_html(pretty=False))
# <pre>```
# <img src=x onerror=alert(1)></pre>
print(doc.to_markdown())
# ```
# ```
# <img src=x onerror=alert(1)>
# ```
Rendered as CommonMark/GFM-style Markdown, that output is interpreted as:
- Line 1 opens a fenced code block
- Line 2 closes it
- Line 3 is raw HTML outside the fence
- Line 4 opens a new fence
Root Cause
The <pre> Markdown serializer uses a fixed fence instead of selecting a delimiter longer than the longest backtick run in the content.
Impact
Applications that treat JustHTML(..., sanitize=True).to_markdown() output as safe for direct rendering in Markdown contexts may be exposed to XSS, depending on the downstream Markdown renderer's raw-HTML handling.
Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
When serializing <pre> content to Markdown, choose a fence length longer than any backtick run present in the code block content, with a minimum length of 3.
Frequently Asked Questions
- What is GHSA-5VP3-3CG6-2RQ3? GHSA-5VP3-3CG6-2RQ3 is a high-severity cross-site scripting (XSS) vulnerability in justhtml (pip), affecting versions <= 1.12.0. It is fixed in 1.13.0. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
- Which versions of justhtml are affected by GHSA-5VP3-3CG6-2RQ3? justhtml (pip) versions <= 1.12.0 is affected.
- Is there a fix for GHSA-5VP3-3CG6-2RQ3? Yes. GHSA-5VP3-3CG6-2RQ3 is fixed in 1.13.0. Upgrade to this version or later.
- Is GHSA-5VP3-3CG6-2RQ3 exploitable, and should I be worried? Whether GHSA-5VP3-3CG6-2RQ3 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-5VP3-3CG6-2RQ3 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-5VP3-3CG6-2RQ3? Upgrade
justhtmlto 1.13.0 or later.