Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.tohtml() (verified at v3.2.6, lines ~57–65): Two neutralization failures compound: 1. Markdown → HTML is unsanitized. python-markdown passes raw HTML through by default: <img src=x onerror=…, <svg onload=…,…
Recommended action: Upgrade to 3.2.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A missing comma in mercuryapp/blockhandler.py's BLOCKEDPATTERNS 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 mercuryapp/blockhandler.py is defined as: 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/),…
Recommended action: Upgrade to 3.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Mercury runs a JupyterLab server with anonymous access by default (mercuryapp/main.py sets --IdentityProvider.token='' when no --token/MERCURYTOKEN is given; when tokenless it also sets --ServerApp.disablecheckxsrf=True). It relies on a blocklist (mercuryapp/blockhandler.py BLOCKEDPATTERNS: /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 patchkernelwebsockethandler() (mercuryapp/idletimeout.py) only tracks the idle-timeout: it wraps onmessage to call self.application.timeoutmanager.touch() and then invokes the original handler with no filtering of executerequest. So any unauthenticated network client can: 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…
Recommended action: Upgrade to 3.2.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.