Mercury: Stored / DOM Cross-Site Scripting (XSS): mr.Markdown renders untrusted content as raw, unsanitized HTML

Threat model (attacker → victim, not self-inflicted)

The CVE-relevant framing is data-driven: the app author writes ordinary code, and the data is attacker-controlled.

import mercury as mr
# `row` comes from a DB / user submission / uploaded file / external API —
# i.e. NOT authored by the app developer:
mr.Markdown(row["comment"])

The attacker supplies the untrusted value (posts the comment, uploads the file, poisons the API/RAG source). A different user — another app user, a reviewer, an admin — then opens the app, and the payload executes in their browser. The vulnerable component (Mercury's server-side widget rendering) and the impacted component (the victim's browser session in the app origin) differ, which is the classic stored-XSS attacker/victim separation.

Amplifier — session sharing (--keep-session). Mercury can serve one shared kernel session to all viewers (mercury run … --keep-session, README "Arguments": "share the same session between multiple users … others will see this"). It is opt-in and defaults to off (keepSession=False in mercury_app/handlers.py), so it is not required for the base case — any app that renders one user's untrusted data to another user is already vulnerable. When enabled, content one viewer submits is rendered into the session other viewers see, extending this to cross-user delivery. Authentication is opt-in and off by default: a free password gate exists (mercury run … --pass=…, README), while user-based authentication is a paid add-on. Because auth is off unless the operator enables it, unauthenticated public deployments — where the attacker needs no account — are a realistic default.

Proof of Concept

import mercury as mr

# Value that would realistically arrive from untrusted data (DB row, form field,
# uploaded file, API/LLM response):
untrusted = '<img src=x onerror=alert(String.fromCharCode(88,83,83))>'

mr.Markdown(untrusted)   # rendered to raw HTML, unsanitized, into the app DOM

The generated widget HTML contains the payload verbatim; when the widget is displayed, the onerror handler runs.

What was confirmed (and how)

• Confirmed by execution in a real browser (sink level): driving the actual python-markdown output into the same ipywidgets.HTML value sink the widget uses causes the payload to execute in headless Chromium. Execution was captured via Playwright's dialog event (which fires only on a genuine alert(), so the mere presence of the string in the HTML cannot cause a false positive). A benign control (**hello**) produced zero dialogs, confirming the harness reports only real execution. python-markdown passes <img src=x onerror=…> through verbatim by default (behavior is not version-specific).
• Reasoned from source (not executed end-to-end): the full path from a mr.Markdown(...) call in a served Mercury app to a viewer's DOM was not run end-to-end, because no isolated container/VM was available in the reporting environment. Because MarkdownWidget is the ipywidgets.HTML sink above and Mercury's frontend applies no sanitizer to widget HTML values (the only frontend sanitizer strips notebook metadata at save time), the served-app path is expected to behave identically. Reproduce end-to-end before publishing if you want the advisory to state full-path browser confirmation.

Impact

Mercury shares notebooks as web apps/dashboards, often for non-technical audiences. When an app renders untrusted data through mr.Markdown, the generated page carries attacker-controlled script that runs in the browser of any other viewer, in the app origin — enabling session/cookie/token theft, UI spoofing and forced actions as the victim, and pivoting within the hosting origin. With --keep-session, this extends to cross-user delivery within a shared session.

Severity rationale (CVSS 3.1 per-metric)

Base score reflects the realistic default: an unauthenticated deployment whose app renders untrusted data via mr.Markdown.

Result: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1 (Medium).

Deployment-dependent variants (state your environment's when filing):

• Injection channel requires an authenticated low-privilege user → PR:L → …/PR:L/UI:R/S:C/C:L/I:L/A:N = 5.4.
• App origin exposes high-value auth material such that XSS yields full session/account takeover → C:H/I:H raises the score; justify per deployment rather than claiming it universally.

Remediation

Primary — sanitize by default in mr.Markdown, with an explicit opt-out for the deliberate raw-HTML use case (backward-compatible, non-breaking):

# mercury/md.py
def _to_html(self, text: str, unsafe_allow_html: bool = False) -> str:
    if md_lib is not None:
        body = md_lib.markdown(text)
    else:
        body = f"<pre>{escape(text)}</pre>"
    if not unsafe_allow_html:
        # allowlist tags/attributes; strip javascript:/data: schemes and event handlers
        body = nh3.clean(body)            # or bleach.clean(..., strip=True)
    return self._apply_inline_theme(body)

Expose unsafe_allow_html=False on mr.Markdown(...) so authors who deliberately embed trusted raw HTML can opt in, while the default is safe. This mirrors the convention used by comparable tools (e.g. Streamlit's unsafe_allow_html).

Defense-in-depth: since widget HTML values are written via innerHTML without sanitization, consider sanitizing widget HTML values at the frontend before they reach the DOM, and/or serving a Content-Security-Policy that forbids inline event handlers, so a single missed sink is not immediately exploitable.

Additional hardening (secondary — not the reported vulnerability)

Several widget ESMs write the label with innerHTML, e.g. mercury/text.py topLabel.innerHTML = model.get("label") || … (same shape in number.py, time.py, date/datetime/daterange/select/json/file, and indicator.py's _card_html). This is not an attacker→victim XSS path: labels are static strings set by the app author in Python; URL/url_params overrides affect only widget value (assigned via the safe input.value property), never label, so there is no end-user/URL route into a label. It is a defense-in-depth / author footgun only. Recommended regardless: render UI strings with textContent, or html.escape labels, so output encoding is applied uniformly.