CVE-2026-111058 in Mercury
Summary
by MITRE • 10/19/2026
Mercury is a Python framework for sharing Jupyter notebooks as web applications and dashboards. Prior to 3.2.6, default tokenless deployments allow anonymous clients to create Jupyter kernels and send execute_request messages containing arbitrary Python. The endpoint blocklist does not cover /api/kernels, and the websocket wrapper previously tracked idle activity without authorizing executable messages. This issue is fixed in version 3.2.6.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in Mercury versions prior to 3.2.6 represents a critical authentication bypass within a Python framework designed for sharing Jupyter notebooks as web applications and dashboards. The core of the issue lies in the default configuration, which permits tokenless deployments that fail to enforce strict access controls on backend execution endpoints. In these unpatched configurations, anonymous clients are able to interact directly with the underlying Jupyter infrastructure without providing valid authentication credentials or tokens. This architectural flaw allows external actors to establish direct communication channels with the server-side components responsible for code execution, effectively bypassing the intended security boundaries of the application layer.
Technically, the vulnerability stems from two specific implementation failures within the Mercury framework's handling of WebSocket connections and API endpoints. First, the endpoint blocklist mechanism, which is designed to restrict access to sensitive Jupyter APIs, fails to include the /api/kernels endpoint. This oversight allows unauthenticated users to initiate new kernel sessions via standard HTTP requests. Second, the websocket wrapper logic previously tracked idle activity without properly authorizing executable messages sent over these connections. Consequently, once a connection is established, an attacker can send execute_request messages containing arbitrary Python code directly to the running kernels. The framework does not validate whether the client has legitimate permission to submit such commands, leading to unrestricted remote code execution capabilities for any network-accessible user.
The operational impact of this vulnerability is severe, as it effectively grants full control over the server environment hosting the Mercury application. An attacker can exploit this flaw to execute arbitrary Python scripts with the privileges of the process running the Jupyter kernel. This capability enables a wide range of malicious activities, including data exfiltration from accessible files and databases, installation of backdoors or malware on the host system, lateral movement within internal networks if the server has broader connectivity, and complete denial of service through resource exhaustion attacks such as infinite loops or memory leaks. Since Jupyter kernels often run with elevated privileges to facilitate development tasks, the compromise can extend beyond the application itself to affect the entire underlying operating system infrastructure.
This vulnerability aligns closely with CWE-287, which describes Improper Authentication, specifically where an actor is able to bypass authentication mechanisms due to misconfiguration or logic errors in access control enforcement. Furthermore, from a threat modeling perspective consistent with MITRE ATT&CK frameworks, this exploit maps to T1059 Command and Scripting Interpreter, as it allows the execution of arbitrary code via Python commands, and potentially T1136 Creation of Account if the attacker creates new user accounts for persistence. The attack vector is classified under Remote Code Execution (RCE) facilitated by a broken access control mechanism that fails to validate identity before allowing privileged operations.
To mitigate this vulnerability, organizations must immediately upgrade Mercury to version 3.2.6 or later, where these authentication checks and endpoint restrictions have been corrected. For environments unable to patch immediately due to compatibility constraints, it is critical to enforce token-based authentication for all Jupyter kernel interactions rather than relying on default tokenless settings. Additionally, network-level controls such as firewalls should be configured to restrict access to the /api/kernels endpoint exclusively to trusted internal IP ranges or authenticated proxies. Regular security audits of framework configurations and continuous monitoring for unauthorized kernel creation activities are also recommended to detect potential exploitation attempts in real-time.