CVE-2026-111058 is a remote-code-execution flaw in Mercury, the Python framework and standalone server used to turn Jupyter notebooks into browser applications, dashboards, reports and model-driven tools. That puts it in the hands of data-science, analytics, research and Python teams—often to share calculations or predictions with business users and other non-programmers. No authoritative public list identifies organisations running self-hosted Mercury.
The dangerous part is Mercury’s default tokenless mode. When an operator has not supplied a token, anonymous visitors can reach its Jupyter server. Mercury tried to limit that exposure with a blocklist of sensitive Jupyter routes, but its advisory says /api/kernels was not blocked. It cannot simply be blocked: Mercury needs kernels to run notebook workloads.
A browser client becomes a Python caller
An unauthenticated network client could ask /api/kernels to create a Python kernel, open that kernel’s WebSocket channel, then submit Jupyter’s execute_request message with attacker-chosen Python. In plain terms, the application exposed a service designed to execute notebook code, and allowed an anonymous visitor to provide the code. The result is arbitrary Python execution in the Mercury server’s security context—along with whatever files, credentials, network access and cloud permissions that process can reach.
The earlier terminal-path issue, GHSA-f8c7-rwf9-fmgm, does not solve this one. Mercury 3.2.4 closed /api/terminals, yet vendor testing found kernel creation and execution still worked. The vulnerable WebSocket wrapper merely refreshed an idle timer and passed every message through unchanged:
def on_message_with_touch(self, message):
if hasattr(self.application, "_timeout_manager"):
logger.debug("[Idle Timeout] touch() via WebSocket message (KernelWebsocketHandler)")
self.application._timeout_manager.touch()
return orig_on_message(self, message)Notice what is absent: no check that an execution request belongs to an authorised Mercury session, and no restriction on supplied code.
Upgrade rather than relying on route filtering
The affected range is Mercury 3.2.5 and earlier; 3.2.6, released August 28, 2026, fixes the issue. The fix behind GHSA-rv4m-xm3f-3ccq is more than another blocklist entry: it adds session and resource ownership controls, rejects direct kernel creation, and constrains execution to server-approved notebook-cell code. Upgrade to 3.2.6 promptly, then review every Mercury instance exposed beyond a trusted network. Until upgraded, do not leave a tokenless server reachable by untrusted clients; restrict network access and require authentication as compensating controls.
Public exploit code exists, including tooling for kernel creation and WebSocket execution, although the report’s submitted deterministic proof of concept is not displayed publicly. There was no confirmed exploitation in the wild as of October 23, 2026, and no CISA KEV entry was found; direct verification against CISA’s downloadable feed could not be completed because it returned HTTP 403. Independent tracking also marks it absent from KEV.
For teams that publish notebook-backed tools, this is a reminder that a Jupyter control plane is not safe to expose just because the intended interface is a dashboard. Upgrade, rotate secrets available to exposed processes if compromise is suspected, and use SecAlerts to monitor the software an organisation actually runs and alert on new vulnerabilities affecting it.
