Key points
- CVE-2026-111058 affects Mercury versions before 3.2.6 and carries a CVSS score of 9.8.
- The flaw permits unauthenticated remote code execution via Jupyter kernel creation and message execution.
- Version 3.2.6 is the first release that patches this specific authentication bypass.
The Mercury Python framework contains a critical security vulnerability that allows unauthenticated attackers to execute arbitrary Python code on affected servers. This issue, tracked as CVE-2026-111058, impacts all versions prior to 3.2.6 and has been assigned a CVSS score of 9.8.
What happened
Mercury is designed to share Jupyter notebooks as web applications and dashboards. According to the GitHub advisory GHSA-rv4m-xm3f-3ccq, the application defaults to tokenless access when no token is explicitly configured. This configuration disables cross-site request forgery checks and removes identity provider token requirements.
The software relies on a blocklist to restrict anonymous access to dangerous endpoints. However, the blocklist fails to cover the `/api/kernels` endpoint. As noted in the advisory, this endpoint is essential for running notebooks and therefore cannot be blocked entirely. The websocket wrapper tracks idle activity but does not authorise executable messages sent through this channel.
An attacker can create a new Jupyter kernel by sending a POST request to `/api/kernels`. Once the kernel ID is returned, the attacker opens a websocket connection to the specific kernel channel. Sending an `execute_request` message with arbitrary Python code results in immediate execution on the server.
This vulnerability is distinct from a previous issue, GHSA-f8c7-rwf9-fmgm. That earlier flaw involved a missing comma in the blocklist that allowed access to `/api/terminals`. The fix for that issue did not address the kernel endpoint. Testing on version 3.2.4 confirmed that while terminal access was blocked, kernel-based remote code execution remained possible.
Why it matters
The ability to execute arbitrary code without authentication represents a severe risk to organisations using Mercury. Attackers can gain full control over the server process user. This could lead to data theft, service disruption or further lateral movement within the network.
The default configuration exacerbates the risk. Many deployments may operate without tokens, leaving them exposed by default. The flaw was verified in version 3.2.4, which was released to fix the previous terminal bypass. This indicates that the blocklist approach has fundamental limitations in securing kernel interactions.
What happens next
Organisations must verify their Mercury installations against the affected version range. Users should check their deployment configuration for tokenless settings. Monitoring server logs for unexpected kernel creation events is recommended. Teams should prepare to upgrade to version 3.2.6 as soon as it is available.
Patch priority
Security teams should prioritise updating systems that are exposed to untrusted networks. Check whether Mercury instances are accessible without authentication. Roll out updates to internet-facing servers first. Test the patched version in a staging environment to ensure compatibility with existing notebooks. Back up configuration files before applying updates. If immediate patching is not possible, restrict network access to the Mercury endpoints. Monitor for suspicious kernel creation activity.
Background: Remote code execution vulnerabilities
Remote code execution often occurs because developers trust user input without validation, fail to restrict file permissions, or neglect to update dependencies. Fix these errors by enforcing strict input sanitisation, applying least-privilege principles, and integrating automated security checks into your secure software development lifecycle to prevent arbitrary command execution.
Read the full guide: Seven Configuration Mistakes That Allow Remote Code Execution
What to do and how to stay safe: Mercury
- Audit all Mercury deployments to identify instances running versions prior to 3.2.6.
- Verify that token-based authentication is enabled and enforced on all production systems.
- Restrict network access to Mercury endpoints to trusted internal networks only.
- Monitor server logs for unauthenticated kernel creation attempts and unusual websocket activity.
Step-by-step guide: Patch Management: Definition, Purpose and Operational Reality
General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of Mercury are affected by CVE-2026-111058?
All versions of Mercury prior to 3.2.6 are affected by this vulnerability.
Is there a patch available for this vulnerability?
Yes, version 3.2.6 fixes the unauthenticated remote code execution flaw.
How does this vulnerability differ from the previous terminal bypass?
The previous flaw allowed access to terminals via a blocklist error, while this flaw allows kernel execution which cannot be blocked without breaking functionality.
