Install Mercury 3.2.6 to stop anonymous users from running arbitrary Python code via exposed servers
Default tokenless deployments of the Mercury framework allow anonymous users to create Jupyter kernels and run arbitrary Python code on exposed servers.
Key points
- CVE-2026-111058 allows unauthenticated remote code execution in Mercury versions prior to 3.2.6.
- The flaw exists because the default blocklist omits the /api/kernels endpoint required for notebook execution.
- Version 3.2.6 patches the vulnerability by enforcing authorization on executable kernel messages.
The Mercury framework, a Python tool for sharing Jupyter notebooks as web applications, contains a critical configuration flaw that enables unauthenticated remote code execution. According to the National Vulnerability Database, versions prior to 3.2.6 allow anonymous clients to create Jupyter kernels and send execute_request messages containing arbitrary Python code. This occurs when deployments use the default tokenless setup, which disables identity tokens and cross-site request forgery checks to facilitate easy access.
The risk
The vulnerability stems from how Mercury manages access to underlying JupyterLab endpoints. The framework relies on a blocklist to restrict anonymous users from dangerous paths like /lab and /api/terminals. However, the /api/kernels endpoint is intentionally excluded from this blocklist because Mercury requires kernel access to run notebooks. A GitHub advisory notes that the websocket wrapper previously tracked idle activity without authorizing the executable messages sent through these channels.
Attackers can exploit this by posting a request to /api/kernels to create a new kernel. They then open a websocket connection to that specific kernel ID and transmit an execute_request message. This allows them to run arbitrary Python code on the server with the privileges of the server process user. The National Vulnerability Database rates this issue as critical with a CVSS score of 9.8.
Who is exposed
Any organization running Mercury versions below 3.2.6 with the default configuration is exposed to this risk. The flaw affects installations where no token is provided, causing the application to set the IdentityProvider token to an empty string. This is the standard default behavior for the framework, meaning many deployments may be vulnerable without explicit misconfiguration by administrators.
The issue is distinct from a previous vulnerability, GHSA-f8c7-rwf9-fmgm, which involved a missing comma in the blocklist allowing access to /api/terminals. While version 3.2.4 fixed that specific bypass, it did not address the kernel execution flaw. The blocklist approach is fundamentally unable to cover kernel endpoints without breaking core functionality, making this a separate structural weakness.
Cost and compliance
The source material does not specify direct financial costs, regulatory penalties, or compliance impacts associated with this vulnerability. No data regarding ransomware demands, legal fines, or insurance implications is provided in the National Vulnerability Database or GitHub advisory records.
Our take on the response
The vendor has released version 3.2.6 to address this critical flaw. Security teams should prioritize updating affected installations immediately, as the default configuration leaves servers open to unauthenticated attacks. This incident highlights the risks of relying on blocklists for security in complex frameworks like Jupyter-based applications.
What defenders should look for
Teams should monitor for unexpected kernel creation events on Jupyter-based servers, particularly from unauthenticated or anonymous sources. Look for websocket connections to kernel endpoints that do not correspond to active user sessions. Check for outbound network traffic from the server process that deviates from normal notebook execution patterns, such as connections to external command and control servers. Review access logs for POST requests to kernel API endpoints that result in successful creation responses.
Background: Ransomware
Ransomware is not just about encryption; it often involves data theft, lateral movement, and human error. Standard antivirus fails against new variants, and backups can become targets. Effective defense requires layered security, strict access controls, and offline storage of critical data copies.
Read the full guide: Ransomware Myths Debunked: The Hidden Truths About Encryption Attacks
What to do and how to stay safe: Mercury
- Update all Mercury installations to version 3.2.6 or later to apply the vendor's fix for the authentication bypass.
- Audit server configurations to ensure that token-based authentication is enforced rather than relying on the default tokenless mode.
- Monitor network traffic for unauthorized websocket connections to Jupyter kernel endpoints that originate from untrusted IP addresses.
- Review access logs for successful POST requests to /api/kernels from users who have not completed standard authentication procedures.
Step-by-step guide: Unpatched Software Response: Containment, Recovery, and Prevention Steps
General security guidance from the BlueTeam Herald newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of Mercury are vulnerable to CVE-2026-111058?
Versions of the Mercury framework prior to 3.2.6 are vulnerable to this unauthenticated remote code execution flaw.
Does version 3.2.4 fix this vulnerability?
No, version 3.2.4 only fixed a previous blocklist bypass for terminals and remains vulnerable to kernel-based code execution.
How do attackers exploit this flaw?
Attackers create a kernel via the API and send arbitrary Python code through a websocket connection without authentication.
