CVE-2026-77088

justhtml versions 0.9.0 through 1.21.0 contain a cross-site scripting vulnerability in to_markdown() where inline code spans fail to account for blank lines as block boundaries. Attackers can inject blank lines into code or pre element text to break the inline span, causing sanitized HTML to be emitted unescaped and re-parsed as live Markdown by compliant renderers.

justhtml versions 0.9.0 through 1.21.0 contain a cross-site scripting vulnerability in to_markdown() where inline code spans fail to account for blank lines as block boundaries. Attackers can inject blank lines into code or pre element text to break the inline span, causing sanitized HTML to be emitted unescaped and re-parsed as live Markdown by compliant renderers.

justhtml versions 0.9.0 through 1.21.0 contain a cross-site scripting vulnerability in to_markdown() where inline code spans fail to account for blank lines as block boundaries. Attackers can inject blank lines into code or pre element text to break the inline span, causing sanitized HTML to be emitted unescaped and re-parsed as live Markdown by compliant renderers.

justhtml: to_markdown() code-span blank-line breakout enables XSS

Summary

In justhtml 0.9.0 through 1.21.0, to_markdown() renders <code> text (and <pre> text inside a link) as an inline Markdown code span whose only protection is backtick-fence length. A blank line (\n\n) in that text terminates the inline span in any compliant Markdown renderer, so attacker-controlled text that survived HTML sanitization is emitted unescaped after the blank line and is re-parsed as live raw HTML/Markdown — yielding XSS in the default configuration. Likely CWE-79 (Cross-site Scripting) arising from CWE-116 (Improper Encoding/Escaping of Output).

Details

to_markdown() is documented as a safety surface. docs/text.md states the guarantee applies "to the HTML produced by rendering that Markdown with a compliant Markdown renderer," and SECURITY.md promises to_markdown() "escapes line-start Markdown markers that could change block structure" and "uses code fences long enough to contain backticks safely."

The inline code-span helper only sizes the backtick fence; it never accounts for block boundaries:

src/justhtml/node.py:32-41 (tag v1.21.0):

def _markdown_code_span(s: str | None) -> str:
    if s is None:
        s = ""
    # Use a backtick fence longer than any run of backticks inside.
    fence = _markdown_backtick_fence(s, minimum=1)
    # CommonMark requires a space if the content starts/ends with backticks.
    needs_space = s.startswith("`") or s.endswith("`")
    if needs_space:
        return f"{fence} {s} {fence}"
    return f"{fence}{s}{fence}"

The element's text is taken verbatim (strip=False, so embedded newlines are preserved) and routed into that helper:

src/justhtml/node.py:1061-1078 (tag v1.21.0):

            if tag == "pre":
                code = current.to_text(separator="", strip=False)
                if current_in_link:
                    current_builder.raw(_markdown_code_span(code))      # inline path
                else:
                    fence = _markdown_backtick_fence(code, minimum=3)   # block path
                    ...
            if tag == "code" and not current_preserve:
                current_builder.raw(_markdown_code_span(current.to_text(separator="", strip=False)))

A Markdown inline code span is an inline construct and cannot span a block boundary: a blank line ends the paragraph, the opening backticks are left unmatched (literal), and everything after the blank line is parsed as ordinary Markdown — independent of fence length. Because CommonMark passes raw inline HTML through by default, text such as <img src=x onerror=...> becomes a live element.

Reachability with default settings: JustHTML(html) sanitizes by default; <code> and <pre> are in DEFAULT_POLICY.allowed_tags; default sanitization preserves their text and the blank line (whitespace collapsing is opt-in). The payload lives in text, not a URL attribute, so URL-scheme sanitization never applies. The tokenizer decodes character references in normal text before DOM insertion, so <img …> enters the DOM as literal <img …> text while passing HTML sanitization.

Two in-repo asymmetries confirm this is an unguarded path rather than intended behavior:

• Plain text-node content is HTML-escaped before Markdown escaping, so the same <img …> outside a code span is neutralized to <img …>. Inside a code span it is not escaped — the fence is assumed sufficient.
• <pre> outside a link uses a block fence (minimum=3, line 1066), which a blank line cannot break. The same <pre> inside a link (line 1064) and all <code> use the inline span, which a blank line breaks.

PoC

Self-contained, runs entirely in Docker against the pinned PyPI release. Static by default: the rendered HTML is parsed to show a live handler-bearing element materializes; no JavaScript is executed on the default path. …

justhtml versions 0.9.0 through 1.21.0 contain a cross-site scripting vulnerability in to_markdown() where inline code spans fail to account for blank lines as block boundaries. Attackers can inject blank lines into code or pre element text to break the inline span, causing sanitized HTML to be emitted unescaped and re-parsed as live Markdown by compliant renderers.

justhtml versions 0.9.0 through 1.21.0 contain a cross-site scripting vulnerability in to_markdown() where inline code spans fail to account for blank lines as block boundaries. Attackers can inject blank lines into code or pre element text to break the inline span, causing sanitized HTML to be emitted unescaped and re-parsed as live Markdown by compliant renderers.

justhtml: to_markdown() code-span blank-line breakout enables XSS

Summary

In justhtml 0.9.0 through 1.21.0, to_markdown() renders <code> text (and <pre> text inside a link) as an inline Markdown code span whose only protection is backtick-fence length. A blank line (\n\n) in that text terminates the inline span in any compliant Markdown renderer, so attacker-controlled text that survived HTML sanitization is emitted unescaped after the blank line and is re-parsed as live raw HTML/Markdown — yielding XSS in the default configuration. Likely CWE-79 (Cross-site Scripting) arising from CWE-116 (Improper Encoding/Escaping of Output).

Details

to_markdown() is documented as a safety surface. docs/text.md states the guarantee applies "to the HTML produced by rendering that Markdown with a compliant Markdown renderer," and SECURITY.md promises to_markdown() "escapes line-start Markdown markers that could change block structure" and "uses code fences long enough to contain backticks safely."

The inline code-span helper only sizes the backtick fence; it never accounts for block boundaries:

src/justhtml/node.py:32-41 (tag v1.21.0):

def _markdown_code_span(s: str | None) -> str:
    if s is None:
        s = ""
    # Use a backtick fence longer than any run of backticks inside.
    fence = _markdown_backtick_fence(s, minimum=1)
    # CommonMark requires a space if the content starts/ends with backticks.
    needs_space = s.startswith("`") or s.endswith("`")
    if needs_space:
        return f"{fence} {s} {fence}"
    return f"{fence}{s}{fence}"

The element's text is taken verbatim (strip=False, so embedded newlines are preserved) and routed into that helper:

src/justhtml/node.py:1061-1078 (tag v1.21.0):

            if tag == "pre":
                code = current.to_text(separator="", strip=False)
                if current_in_link:
                    current_builder.raw(_markdown_code_span(code))      # inline path
                else:
                    fence = _markdown_backtick_fence(code, minimum=3)   # block path
                    ...
            if tag == "code" and not current_preserve:
                current_builder.raw(_markdown_code_span(current.to_text(separator="", strip=False)))

A Markdown inline code span is an inline construct and cannot span a block boundary: a blank line ends the paragraph, the opening backticks are left unmatched (literal), and everything after the blank line is parsed as ordinary Markdown — independent of fence length. Because CommonMark passes raw inline HTML through by default, text such as <img src=x onerror=...> becomes a live element.

Reachability with default settings: JustHTML(html) sanitizes by default; <code> and <pre> are in DEFAULT_POLICY.allowed_tags; default sanitization preserves their text and the blank line (whitespace collapsing is opt-in). The payload lives in text, not a URL attribute, so URL-scheme sanitization never applies. The tokenizer decodes character references in normal text before DOM insertion, so <img …> enters the DOM as literal <img …> text while passing HTML sanitization.

Two in-repo asymmetries confirm this is an unguarded path rather than intended behavior:

• Plain text-node content is HTML-escaped before Markdown escaping, so the same <img …> outside a code span is neutralized to <img …>. Inside a code span it is not escaped — the fence is assumed sufficient.
• <pre> outside a link uses a block fence (minimum=3, line 1066), which a blank line cannot break. The same <pre> inside a link (line 1064) and all <code> use the inline span, which a blank line breaks.

PoC

Self-contained, runs entirely in Docker against the pinned PyPI release. Static by default: the rendered HTML is parsed to show a live handler-bearing element materializes; no JavaScript is executed on the default path. …