Mercury CVE-2026-111059

Exploitation requires a Mercury application (versions 3.0.0 through 3.2.10) that passes attacker-controllable data into the mr.Markdown widget - specifically database rows, user form submissions, uploaded file contents, or external/LLM API responses rendered as Markdown; the prior mr.Message markdown path is affected by the same unsanitized renderer. The malicious payload is active HTML such as event-handler attributes (onerror/onload) or javascript: links. Exploitation is LIMITED by required user interaction (UI:R): a second user must view the app containing the injected content for the script to run in their browser. It does NOT affect apps that render only trusted, author-written Markdown, and it is neutralized in 3.2.11 (which sanitizes by default unless the developer explicitly opts in with unsafe_allow_html=True).

This is a stored/DOM-based XSS (CWE-79) in the mr.Markdown rendering sink of the Mercury framework, with an input CVSS of 6.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N). The signals point to a moderate, conditional risk rather than a drop-everything priority. No EPSS score was provided in the input, no CISA KEV listing is present, and no public proof-of-concept is referenced - so exploitation is: no public exploit identified at time of analysis. No SSVC decision data was supplied. The CVSS vector indicates network vector, low complexity, no privileges (PR:N) and required user interaction (UI:R), which aligns with the description: code executes 'when another user views the application.' The one important nuance is that this is not a flaw that fires against a stock install - it only becomes exploitable when a Mercury app is built to pass untrusted data (DB rows, user submissions, uploaded files, or LLM/API responses) into mr.Markdown. The advisory explicitly frames it as a library sink that fails to neutralize output and is triggered by 'ordinary, reasonable application code,' which raises real-world likelihood among apps that render user- or AI-supplied content, but leaves apps that render only trusted author content unaffected. Net: a legitimate issue worth patching, but its real-world severity is gated by application design, and the absence of KEV/POC/EPSS signals suggests no evidence of active or widespread exploitation.

A developer builds a Mercury app (e.g., a dashboard or chat/LLM front-end) that feeds user submissions, uploaded file contents, or an LLM API response into mr.Markdown. An attacker submits Markdown containing active HTML such as '<img src=x onerror=...>' or '<svg onload=...>'; because python-markdown passes raw HTML through and the ipywidgets.HTML widget writes it to the DOM via innerHTML unsanitized, the payload executes in the browser of any other user who later views the app. No public exploit code is referenced, but the payloads named in the advisory are trivial to construct.