CVE-2026-111059

Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. From 3.0.0 until 3.2.11, mr.Markdown converts attacker-controlled Markdown to HTML without sanitizing raw HTML before assigning it to an ipywidgets.HTML sink. Event-handler attributes and other active HTML can therefore reach the DOM and execute when another user views the application. This issue is fixed in version 3.2.11.

Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. From 3.0.0 until 3.2.11, mr.Markdown converts attacker-controlled Markdown to HTML without sanitizing raw HTML before assigning it to an ipywidgets.HTML sink. Event-handler attributes and other active HTML can therefore reach the DOM and execute when another user views the application. This issue is fixed in version 3.2.11.

Summary

Mercury turns Jupyter notebooks into shared web apps/dashboards. The mr.Markdown widget converts its input to HTML with python-markdown and no sanitization step. MarkdownWidget is an ipywidgets.HTML widget, whose value is written to the page as raw HTML (via innerHTML) with no sanitization, so the result reaches the DOM verbatim. When an app passes untrusted data (database rows, user submissions, uploaded file contents, or an external/LLM API response) to mr.Markdown, HTML/JS in that data executes in the browser of whoever views the app — a data-driven stored/DOM-based XSS.

This is a library-provided rendering sink that fails to neutralize output; it is triggered by ordinary, reasonable application code, not by an author mistake.

Root cause

mercury/md.py — MarkdownWidget._to_html() (verified at v3.2.6, lines ~57–65):

def _to_html(self, text: str) -> str:
    if md_lib is not None:
        body = md_lib.markdown(text)          # python-markdown: passes raw HTML through
    else:
        body = f"<pre>{escape(text)}</pre>"   # escape() is ONLY the md-lib-absent fallback
    return self._apply_inline_theme(body)     # regex styling — adds style=, removes nothing

Two neutralization failures compound:

1. Markdown → HTML is unsanitized. python-markdown passes raw HTML through by default: <img src=x onerror=…>, <svg onload=…>, and javascript: links survive verbatim. There is no bleach/nh3 allowlist anywhere in the package. _apply_inline_theme() only injects inline style= attributes via regex; it is not a sanitizer and removes nothing. escape() runs only in the md-lib-absent fallback.

2. The rendering sink is unsanitized innerHTML. MarkdownWidget (mercury/md.py:21) subclasses ipywidgets.HTML. The ipywidgets HTML widget renders its value into the DOM as raw HTML via innerHTML, with no sanitization (this is the widget's design). Event-handler payloads such as <img src=x onerror=…> therefore execute when the widget is displayed.

On the "sanitize" that exists: mercury_app/notebook_sanitize.py (sanitize_notebook_for_mercury_runtime) and packages/lab/src/mercury/save.ts (sanitizeMercuryNotebookContent) strip runtime metadata and clear code-cell saved outputs. They do not neutralize HTML/JS, and they do not touch widget values or markdown source. "Sanitize" here is notebook hygiene, not XSS defense.

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…

Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. From 3.0.0 until 3.2.11, mr.Markdown converts attacker-controlled Markdown to HTML without sanitizing raw HTML before assigning it to an ipywidgets.HTML sink. Event-handler attributes and other active HTML can therefore reach the DOM and execute when another user views the application. This issue is fixed in version 3.2.11.

Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. From 3.0.0 until 3.2.11, mr.Markdown converts attacker-controlled Markdown to HTML without sanitizing raw HTML before assigning it to an ipywidgets.HTML sink. Event-handler attributes and other active HTML can therefore reach the DOM and execute when another user views the application. This issue is fixed in version 3.2.11.

Summary

Mercury turns Jupyter notebooks into shared web apps/dashboards. The mr.Markdown widget converts its input to HTML with python-markdown and no sanitization step. MarkdownWidget is an ipywidgets.HTML widget, whose value is written to the page as raw HTML (via innerHTML) with no sanitization, so the result reaches the DOM verbatim. When an app passes untrusted data (database rows, user submissions, uploaded file contents, or an external/LLM API response) to mr.Markdown, HTML/JS in that data executes in the browser of whoever views the app — a data-driven stored/DOM-based XSS.

This is a library-provided rendering sink that fails to neutralize output; it is triggered by ordinary, reasonable application code, not by an author mistake.

Root cause

mercury/md.py — MarkdownWidget._to_html() (verified at v3.2.6, lines ~57–65):

def _to_html(self, text: str) -> str:
    if md_lib is not None:
        body = md_lib.markdown(text)          # python-markdown: passes raw HTML through
    else:
        body = f"<pre>{escape(text)}</pre>"   # escape() is ONLY the md-lib-absent fallback
    return self._apply_inline_theme(body)     # regex styling — adds style=, removes nothing

Two neutralization failures compound:

1. Markdown → HTML is unsanitized. python-markdown passes raw HTML through by default: <img src=x onerror=…>, <svg onload=…>, and javascript: links survive verbatim. There is no bleach/nh3 allowlist anywhere in the package. _apply_inline_theme() only injects inline style= attributes via regex; it is not a sanitizer and removes nothing. escape() runs only in the md-lib-absent fallback.

2. The rendering sink is unsanitized innerHTML. MarkdownWidget (mercury/md.py:21) subclasses ipywidgets.HTML. The ipywidgets HTML widget renders its value into the DOM as raw HTML via innerHTML, with no sanitization (this is the widget's design). Event-handler payloads such as <img src=x onerror=…> therefore execute when the widget is displayed.

On the "sanitize" that exists: mercury_app/notebook_sanitize.py (sanitize_notebook_for_mercury_runtime) and packages/lab/src/mercury/save.ts (sanitizeMercuryNotebookContent) strip runtime metadata and clear code-cell saved outputs. They do not neutralize HTML/JS, and they do not touch widget values or markdown source. "Sanitize" here is notebook hygiene, not XSS defense.

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…