Mercury Unauthenticated RCE: Missing Comma in Blocklist Exposes Root Shell via /api/terminals

What happened

A security advisory (GHSA-f8c7-rwf9-fmgm, tracked as CVE-2026-111057) discloses a critical unauthenticated remote code execution vulnerability in Mercury, the Python package built on JupyterLab/Jupyter Server for sharing notebooks as web apps. According to the report, the root cause is a missing comma in the BLOCKED_PATTERNS list inside mercury_app/block_handler.py. Two adjacent regex strings were meant to be separate list entries but, due to the missing comma, Python's implicit string concatenation silently merged them into one pattern. The result is that the intended rule blocking /api/terminals never actually takes effect, leaving that endpoint reachable with no authentication.

The advisory includes a working proof-of-concept against a default Docker deployment of Mercury 3.2.3: a plain POST /api/terminals spawns a Jupyter Server terminal, and connecting to the resulting WebSocket allows arbitrary shell commands to be executed. The PoC output shows commands returning as root, i.e., full interactive OS-level access with no login, session, or prior access of any kind. CVSS is reported at 10.0, and the advisory notes a public PoC is available.

Why it matters for defenders

This is as close to worst-case as a web-facing vulnerability gets: no authentication bypass trickery is even needed — the access control for a shell-spawning endpoint is simply absent due to a typo. Any Mercury deployment reachable over a network (including the public internet, per the advisory, if deployed without a reverse proxy, VPN, or firewall in front of it) is exposed to full compromise of confidentiality, integrity, and availability on the host or container running Mercury. Notebooks, uploaded data, environment variables, and secrets accessible to the Mercury process are all at risk, and the advisory specifically calls out the shell as a potential pivot point for lateral movement into other systems reachable from that host.

Organizations running Mercury-hosted notebook apps — internally or exposed to customers/partners — should treat any internet-facing or otherwise unauthenticated-reachable instance as potentially already compromised until patched or mitigated, given the triviality of exploitation and the presence of a public PoC.

What defenders should watch for now

• Inventory any Mercury (mljar/mercury) deployments, especially version 3.2.3 and earlier per the advisory's tested version, and determine network exposure.
• Hunt for unexpected POST requests to /api/terminals or WebSocket connections to /terminals/websocket/* in web/proxy logs, particularly from unauthenticated or unexpected source IPs.
• Review process execution and shell-spawning activity on hosts/containers running Mercury for anomalous child processes under the Mercury/Jupyter Server process tree.
• As an immediate mitigation, restrict network access to Mercury instances (VPN, allowlisted IPs, reverse-proxy authentication) until a patched version incorporating the corrected BLOCKED_PATTERNS list is deployed, and consider blocking /api/terminals and /api/shutdown at a reverse proxy as a stopgap.
• Rotate any secrets or credentials that may have been accessible to a Mercury process on internet-facing hosts, given the risk that this may already be under active exploitation.

Developing intel

This is a same-day disclosure and df00tech has not yet independently verified exploitation in the wild beyond the vendor-published PoC. Details may evolve as patches and further analysis emerge. Full technical details are available in the original GitHub Security Advisory: GHSA-f8c7-rwf9-fmgm.