Mercury 3.2.4 permits unauthenticated network clients to execute arbitrary Python code via the /api/kernels endpoint when the server runs without --token or MERCURY_TOKEN. Exploitation was demonstrated on 3.2.4; the status of other versions, including 3.2.5, remains undocumented. Mercury 3.2.6 restricts anonymous kernel execution to authorized resources only.
How the /api/kernels exposure occurs
Mercury runs a JupyterLab server with anonymous access by default: when neither --token nor MERCURY_TOKEN is supplied, mercury_app/__main__.py sets --IdentityProvider.token='' and --ServerApp.disable_check_xsrf=True. The server relies on a blocklist in mercury_app/block_handler.py to prevent anonymous clients from reaching dangerous Jupyter endpoints.
The blocklist includes /lab, /api/terminals, /api/shutdown, and /files, but does not cover /api/kernels (and cannot, because Mercury needs kernels to run notebooks). The patch_kernel_websocket_handler() function wraps the kernel websocket's on_message method only to track idle timeout and invokes the original handler with no filtering of execute_request messages.
An 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 = RCEThis path remains exploitable even after the fix for a separate /api/terminals blocklist bypass (GHSA-f8c7).
Which versions are documented as affected
The primary advisory demonstrates the vulnerability on Mercury 3.2.4. With the default tokenless configuration, POST /api/kernels returns 201, and opening the kernel websocket executes attacker-supplied Python. The complete affected-version range is not documented in the available sources; the status of 3.2.5 and earlier releases remains unconfirmed.
The documented fix
Mercury 3.2.6, released on August 28, 2026, documents a fix: "Secures anonymous kernel execution by restricting sessions, kernels and notebooks to authorized resources only." The release notes do not detail the implementation.
Remediation
Upgrade to Mercury 3.2.6 or later. If you cannot upgrade immediately, ensure your Mercury server runs with --token or MERCURY_TOKEN configured, which enforces per-request authentication. Never bind Mercury to a non-localhost address (0.0.0.0, public IP, or DNS hostname) without setting a token.
The sources do not document a procedure to check the installed version, verify whether a token is configured, or safely test endpoint access after remediation.
Next step
If you're running Mercury with network exposure, check whether your deployment supplies --token or MERCURY_TOKEN, and upgrade to 3.2.6 or later to ensure anonymous kernel execution is restricted.
Verification status: Supported by official documentation only under the conditions below; not reproduced in a test environment by IGPROD. Checked 2026-10-19.
Applies to: mercury 3.2.4; 3.2.6.
Conditions:
- The documented unauthenticated exposure requires a network client to reach a Mercury server running without --token or MERCURY_TOKEN.
Related advisories
- Mercury unauthenticated RCE in /api/terminals: the first Mercury advisory, with its own fix.
Sources:
