Mercury notebook RCE without login (CVE-2026-111058) [PoC]

Exploitation confirmed - public proof-of-concept - CVE-2026-111058 is a critical unauthenticated remote code execution vulnerability in Mercury prior to 3.2.6, where default tokenless deployments let anonymous clients create Jupyter kernels and execute arbitrary Python on the host. Patched in Mercury 3.2.6 - update immediately if you run a tokenless deployment.

Overview

Mercury is a Python framework for turning Jupyter notebooks into shareable web applications and dashboards. Many deployments run in “tokenless” mode so notebooks can be viewed without authentication. In versions before 3.2.6, that convenience extends to the kernel API.

The endpoint blocklist used to protect sensitive routes did not cover /api/kernels. Combined with a websocket wrapper that tracked idle activity but never authorized executable messages, an anonymous client could open a kernel and send execute_request messages containing arbitrary Python. No credentials, no session, no user interaction required.

This is a textbook case of a denylist that missed a route. The access control model assumed a fixed set of paths to protect rather than authorizing every request that can execute code.

Impact

A successful attacker gets code execution inside the Mercury server process, running with the privileges of the service account. On a typical deployment that means:

• Reading application secrets, environment variables, and mounted credentials
• Accessing any data the notebooks can reach, including upstream databases and cloud APIs
• Using the host as a pivot into the internal network
• Modifying or exfiltrating notebook outputs and user data

Because the CVSS vector is network, low complexity, no privileges, and no user interaction, any publicly reachable tokenless instance is a direct target. An attacker does not need to understand your notebook logic; the kernel executes whatever they send.

Remediation

Upgrade to Mercury 3.2.6, where the kernel endpoints are covered by authorization and websocket messages are checked before execution.

If you cannot upgrade immediately:

1. Require authentication tokens on all deployments. Tokenless mode should never be exposed to untrusted networks.
2. Block /api/kernels and the kernel websocket paths at your reverse proxy or WAF for anonymous clients.
3. Place Mercury behind a VPN or identity-aware proxy until patched.
4. Review logs for unexpected kernel creation or execute_request traffic from unauthenticated sources, and rotate any credentials the service could read.

Note that a denylist fix is only as good as its coverage. Treat the upgrade as the real remediation and the proxy rules as temporary.

For context on how quickly kernel-level flaws get picked up by attackers, see our coverage of CISA adding Linux kernel CVE-2025-39682 to its KEV catalog.

Security Insight

Mercury’s bug is less about a missing check than about a design shortcut: security enforced by enumerating dangerous routes will always lag behind the routes someone adds next. The framework shipped a blocklist and a websocket wrapper that watched activity without deciding whether the sender was allowed to act, which is the classic shape of an authorization gap. For teams running notebook-to-web tooling, the lesson is to assume every execution-capable endpoint is exposed by default and to authenticate it explicitly rather than trusting that a default mode is safe.

Further Reading

• CISA adds Linux kernel CVE-2025-39682 to KEV catalog
• All Critical Vulnerabilities
• Recent Critical Vulnerabilities
• Top Critical CVEs