A missing comma in Mercury 3.2.3's BLOCKED_PATTERNS list permits any unauthenticated attacker who can reach the server to spawn an interactive shell through the /api/terminals endpoint. The flaw causes Python to concatenate two route-blocking patterns, leaving /api/terminals unprotected and reachable without credentials. In the default Docker deployment tested by the project advisory, the shell runs as root.
What the /api/terminals flaw permits
Mercury's mercury_app/block_handler.py defines a blocklist that should prevent access to JupyterLab endpoints. The list includes patterns for /lab, /api/terminals, /api/shutdown, and /files. The missing comma between the first and second line causes Python to merge the two strings, so a direct request to /api/terminals does not match any of the resulting three patterns and passes through to Jupyter Server's terminal API, which spawns a real OS shell accessible over WebSocket with no authentication required.
The GitHub advisory demonstrates the issue on Mercury version 3.2.3 in a default Docker deployment. An attacker sends POST http://localhost:8888/api/terminals, receives a terminal name, connects to the WebSocket at /terminals/websocket/1, and executes commands as root. The proof-of-concept output confirms uid=0(root) gid=0(root) groups=0(root). The attacker gains full read access to any file the Mercury process can access (notebooks, uploaded data, environment variables, secrets), can modify or delete any file the process has write permission for, and can shut down the server or use the shell as a foothold to attack other systems reachable from the host's network.
What is confirmed about affected deployments
The advisory documents exploitation on Mercury version 3.2.3 in the default Docker deployment. The sources do not establish a complete affected version range or document whether earlier releases contain the same flaw.
When the endpoint is exposed
Exploitation requires that a network client can reach the Mercury HTTP port. Deployments accessible from the public internet without additional access controls—VPN, reverse-proxy authentication, or firewall—are immediately exploitable, as are internal deployments reachable by an attacker.
What the release says about the patch
The Mercury v3.2.4 release notes identify the release as a patch for unauthenticated terminal access and reference the advisory. The patch commit adds the missing comma so that /api/terminals becomes an independent blocklist rule and includes a test suite that confirms /api/terminals is blocked.
The sources do not provide a safe procedure to check whether a deployment was compromised or verify that /api/terminals is blocked after remediation.
Next step
Upgrade to Mercury v3.2.4 or apply the comma fix manually if you run an affected version. The sources do not document interim mitigation steps or a safe method to verify endpoint blocking.
Verification status: Supported by official documentation only under the conditions below; not reproduced in a test environment by IGPROD. Checked 2026-10-20.
Applies to: Mercury version 3.2.3.
Conditions:
- An attacker must be able to reach the Mercury server over the network.
- The advisory’s demonstration used Mercury version 3.2.3 in a default local Docker deployment.
- Public internet exposure applies when additional access controls, such as a VPN, reverse-proxy authentication or a firewall, are absent.
Related advisories
- Mercury unauthenticated RCE via /api/kernels: the second Mercury advisory, with its own fix.
Sources:
