GHSA-5vp3-3cg6-2rq3 — justhtml
Fix: EmilStenstrom/justhtml@f35f8f7GHSA-5vp3-3cg6-2rq3 is a CWE-80 vulnerability in justhtml. A fix is available for justhtml — see the affected versions and patch details below.
JustHTML is vulnerable to XSS via code fence breakout in <pre> content
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-5vp3-3cg6-2rq3.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
justhtmlReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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
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.
Root Cause
The <pre> Markdown serializer uses a fixed fence instead of selecting a delimiter longer than the longest backtick run in the content.
Fix
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | justhtml | all versions | 1.13.0pip install --upgrade 'justhtml==1.13.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for justhtml, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update justhtml to 1.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-5vp3-3cg6-2rq3 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-5vp3-3cg6-2rq3 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-5vp3-3cg6-2rq3. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-5vp3-3cg6-2rq3 in your dependencies?
O3 Security finds GHSA-5vp3-3cg6-2rq3 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.