On this page (7 sections)
Mercury, a Python framework that turns Jupyter notebooks into web apps and dashboards, has a critical flaw tracked as CVE-2026-111057. A single missing comma in its endpoint blocklist let any unauthenticated client reach Jupyter Server's terminal API and open an interactive operating-system shell on the host. Per the GitHub advisory, it is fixed in Mercury 3.2.4.
A second, separate advisory, CVE-2026-111058, shows that 3.2.4 is not enough on default deployments: anonymous clients can still run Python through the kernel API until you reach 3.2.6. If you host Mercury apps anywhere that is not strictly private, treat this as urgent.
What happened
Mercury keeps anonymous visitors away from dangerous Jupyter endpoints with a blocklist of URL patterns in mercury_app/block_handler.py. According to the advisory, a comma was missing between the first and second entries. Python joins adjacent string literals, so the pattern for /lab and the pattern for /api/terminals were merged into one rule that no longer matched a plain request to /api/terminals.
The result: the terminal API was never blocked. It spawns a real OS shell reachable over a WebSocket, and no account, session or prior access to Mercury is required. The advisory's author reports testing on a local Docker deployment of version 3.2.3 in the default configuration and obtaining a root shell inside that container.
Why a missing comma matters: the weakness class
The flaw is catalogued as CWE-185 (incorrect regular expression) and CWE-284 (improper access control). The deeper problem is the design: a blocklist tries to name everything dangerous, and any gap silently becomes an open door. A typo in a list of patterns turned an access control into a no-op without any error or warning.
The follow-up advisory makes this point directly. It states that Mercury runs with anonymous access by default and that the blocklist approach cannot cover /api/kernels, because Mercury needs kernels to run notebooks. The second advisory credits Abdullah Kareem (GitHub: CyberKareem) as the finder and reports that on 3.2.4 the terminal request returned 403 while a kernel request still succeeded, allowing arbitrary Python execution as the server process user.
Who is affected
- Anyone running Mercury 3.0.0 through 3.2.3 (CVE-2026-111057).
- Anyone running Mercury 3.2.5 or earlier in the default tokenless setup (CVE-2026-111058). Per the advisory, the default sets an empty token and disables the XSRF check when no token is provided.
- Deployments reachable by untrusted clients. The advisory says any network client that can reach the server can exploit it, including the public internet if there is no VPN, reverse-proxy authentication or firewall in front.
- Hosts where the Mercury process can read secrets, notebooks, uploaded data or environment variables, or where it can reach other internal systems. The advisory lists these as the impact, including use as a foothold for lateral movement.
The research does not say how many Mercury instances are exposed to the internet, and no in-the-wild exploitation is reported. Public proof-of-concept details exist, so do not wait for that to change.
How to check your exposure
First find out which version you run. This read-only command, run in the same Python environment (or container) as Mercury, prints the installed package version. You need 3.2.6 or later.
pip show mercuryIf you deploy with Docker, run the same command inside the container, or check which Mercury version your image pins in its requirements. Then review who can reach the service: from a machine outside your trusted network, confirm that the Mercury port is not reachable, or that it sits behind authentication you control.
Also look at your web server or proxy logs for requests to /api/terminals, /terminals/websocket, /api/kernels or /api/kernels/.../channels from addresses you do not recognize. This read-only search assumes a typical access log path, so adjust it to yours.
grep -E '/api/terminals|/terminals/websocket|/api/kernels' /var/log/nginx/access.logHits from your own users are expected for /api/kernels, since Mercury needs it to run notebooks. Look instead for unknown source IPs, POST requests to /api/terminals, or WebSocket connections you cannot explain. Absence of log entries does not prove safety, because WebSocket traffic is often logged poorly.
What to do now
This upgrades Mercury to the release that fixes both issues. Run it in the Mercury environment, then restart the service or rebuild the container using your normal process.
pip install --upgrade "mercury>=3.2.6"After upgrading, re-run the version check above and confirm it reports 3.2.6 or later.
0 of 7 done
Detection and monitoring afterwards
Keep watching for outbound connections from the Mercury host to unfamiliar destinations, new files in temporary directories, and new shell or Python child processes of the Mercury service. These are what abuse of a terminal or kernel API would look like on the host.
From the outside, you can confirm what your public address exposes. Webforta Scan runs read-only scans of sites you verify, and Webforta Monitor can alert you to certificate, DNS and header changes. Neither replaces patching or putting authentication in front of internal tools. For background on filtering traffic in front of an app, see What is a WAF?
Timeline
| Date | Event |
|---|---|
| Aug 21, 2026 | Terminals advisory (GHSA-f8c7-rwf9-fmgm) published to the mljar/mercury repository |
| Aug 31, 2026 | Kernels advisory (GHSA-rv4m-xm3f-3ccq) published to the repository |
| Oct 19, 2026 | Both advisories added to the GitHub Advisory Database and reviewed; CVE records published |
The fixes are in the v3.2.4 release and the 3.2.6 release. At the time of writing, only the GitHub advisories cover this story, so there is no independent confirmation beyond the maintainers' and reporters' own write-ups.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.