NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐍 PyPI
Not in CISA KEV

CVE-2026-5389 — justhtml

Fix: EmilStenstrom/justhtml@f35f8f7

CVE-2026-5389 is a CWE-80 vulnerability in justhtml. A fix is available for justhtml — see the affected versions and patch details below.

justhtml before 1.13.0 XSS via code fence breakout

Also known asGHSA-5vp3-3cg6-2rq3
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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 CVE-2026-5389.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs14th percentile — riskier than 14% of all scored CVEsHighest risk
0.00%0.25%0.51%0.76%0.2%0.3%0.2%0.2%Sep 26Nov 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐍justhtml

Real-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 &lt;img ...&gt;, 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>&#96;&#96;&#96;\n&lt;img src=x onerror=alert(1)&gt;</pre>"
doc = JustHTML(payload, fragment=True)  # default sanitize=True

print(doc.to_html(pretty=False))
# <pre>```
# &lt;img src=x onerror=alert(1)&gt;</pre>

print(doc.to_markdown())
# ```
# ```
# <img src=x onerror=alert(1)>
# ```

Rendered as CommonMark/GFM-style Markdown, that output is interpreted as:

  1. Line 1 opens a fenced code block
  2. Line 2 closes it
  3. Line 3 is raw HTML outside the fence
  4. 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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIjusthtmlall versions1.13.0pip install --upgrade 'justhtml==1.13.0'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. Fix

    Update justhtml to 1.13.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-5389 is resolved across your whole dependency graph.

  3. Workarounds

    Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.

Frequently Asked Questions

## 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
O3 Security · Impact-Aware SCA

Is CVE-2026-5389 in your dependencies?

Find it across PyPI, including transitive dependencies.

CVE-2026-5389: justhtml XSS — Fixed in 1.13.0