Mercury Notebook Server: Unauthenticated RCE via /api/kernels Bypasses Prior Fix (CVE-2026-111058)

What happened

A new GitHub Security Advisory (GHSA-rv4m-xm3f-3ccq, CVE-2026-111058) discloses an unauthenticated remote code execution vulnerability in Mercury, a Python package for turning Jupyter notebooks into web apps. By default, Mercury runs an embedded JupyterLab server with anonymous access enabled (an empty identity token and XSRF checks disabled when no token is configured), relying on a blocklist of dangerous endpoints (/lab, /api/terminals, /api/shutdown, /files) to keep unauthenticated users contained.

According to the advisory, /api/kernels is not on that blocklist — and the researcher argues it structurally cannot be, since Mercury needs kernel access to execute notebooks. The code that patches the kernel websocket handler only tracks idle-timeout activity and does not filter execute_request messages. The advisory states this was runtime-verified on Mercury 3.2.4 (the version that already fixed a related, separate advisory, GHSA-f8c7-rwf9-fmgm, for /api/terminals): an unauthenticated client can create a kernel via POST /api/kernels, open its websocket, and send an execute_request to run arbitrary Python as the server process. A public PoC is referenced. CVSS is listed at 9.8.

Why it matters

If accurate, this affects any default (tokenless) Mercury deployment reachable over a network — which per the advisory is the out-of-the-box configuration. Because the issue lives in how kernel websocket messages are handled rather than in the endpoint blocklist, the earlier fix for the /api/terminals issue does not address it, and the advisory argues no additional blocklist entry can. Successful exploitation means full code execution as the Mercury server process user, with the blast radius extending to whatever data, credentials, or network access that process has.

What defenders should do now

• Identify any Mercury deployments in your environment and check whether they are running without an explicit token/password (the default, tokenless state is what the advisory describes as exposed).
• Treat any internet- or network-reachable Mercury instance as high risk until a fix is confirmed available; restrict network access to trusted hosts in the interim.
• Hunt for unexpected POST /api/kernels requests from unauthenticated or unexpected clients in web/proxy logs, and for anomalous child processes or outbound activity spawned by the Mercury server process.
• Watch for unusual Python execution patterns originating from the Mercury process (e.g., shell commands, file writes, or network connections not consistent with normal notebook execution).
• Monitor the upstream repository and advisory for a patched release, and prioritize requiring real authentication (token or password) on any Mercury instance rather than relying on endpoint blocking.

Developing intel

This is based on a same-day GHSA disclosure and reflects the researcher's reported findings and runtime testing as described in the advisory; patch status and vendor response were not detailed at time of writing. This post will be updated as more information becomes available. See the original advisory for full technical details: GHSA-rv4m-xm3f-3ccq.