Key points
- The vulnerability affects Mercury versions prior to 3.2.6 and is rated critical with a CVSS score of 9.8.
- Attackers can exploit the default tokenless configuration to create kernels and execute arbitrary Python commands remotely.
- A patch is available in version 3.2.6, which addresses the unauthenticated remote code execution issue.
Mercury versions earlier than 3.2.6 are affected by a critical vulnerability that allows unauthenticated remote code execution. The flaw exists in the default configuration, which often runs without authentication tokens. This setup enables anonymous clients to interact with the server’s kernel management endpoints. According to the National Vulnerability Database, the issue carries a CVSS score of 9.8.
In plain English
Mercury is a Python framework designed to share Jupyter notebooks as web applications. By default, it often starts without requiring a login token. This means anyone on the network can access the service. The application uses a blocklist to restrict access to certain dangerous endpoints. However, the blocklist fails to protect the kernel creation endpoint. Attackers can use this gap to start new kernels and send commands.
The background
The vulnerability stems from how Mercury handles anonymous access and endpoint protection. When no token is provided, the application disables cross-site request forgery checks. It relies on a blocklist to stop users from accessing sensitive paths like terminals or shutdown commands. The `/api/kernels` endpoint is not blocked because the system needs it to run notebooks. The websocket wrapper tracks idle time but does not filter executable messages. This allows arbitrary Python code execution.
What changes now
Version 3.2.6 fixes this issue by addressing the unauthenticated access problem. The update ensures that anonymous clients cannot create kernels or execute code without proper authorization. Users running versions prior to 3.2.6 remain exposed to this risk. The previous fix for a related terminal bypass did not resolve this kernel issue. Teams must upgrade to the latest version to mitigate the threat.
Who needs to act first
Security teams should prioritize updating systems exposed to untrusted networks or the internet. Start with public-facing dashboards and shared development environments. Test the update in a staging environment to ensure compatibility with existing notebooks. Back up configuration files before applying the patch. If immediate updating is not possible, restrict network access to the Mercury service using firewalls. Monitor logs for unauthorized kernel creation attempts.
Background: Unauthenticated remote code execution
Unauthenticated remote code execution often stems from default credentials, exposed management interfaces, and improper input handling. Fix these by enforcing strict authentication, disabling unused services, validating all inputs, and isolating privileged components from public networks.
Read the full guide: Unauthenticated RCE Mistakes: 7 Errors That Expose Your Systems
What to do and how to stay safe: Mercury
- Identify all instances of Mercury running versions prior to 3.2.6 in your environment.
- Upgrade to version 3.2.6 as soon as possible to apply the security fix.
- Review network configurations to limit access to Mercury services to trusted users only.
- Monitor server logs for signs of unauthorized kernel creation or suspicious activity.
Step-by-step guide: 7 Configuration Errors That Expose Systems to Zero-Day Exploits
General security guidance from the Vuln Post newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the severity of CVE-2026-111058?
The vulnerability is rated critical with a CVSS score of 9.8.
Which versions of Mercury are affected?
All versions prior to 3.2.6 are vulnerable to this issue.
Is there a fix available?
Yes, version 3.2.6 includes a patch for this vulnerability.
