Security Digest: October 20, 2026 - 1 Critical Vulnerability

Today’s alert is a critical unauthenticated remote code execution issue in Mercury’s default Jupyter-backed deployment. If you run Mercury and have not explicitly enabled strong authentication, treat this as an active compromise risk and move immediately to restrict access, patch, or take the service offline until fixed.

· 16 min read

Executive Summary

Today’s alert is a critical unauthenticated remote code execution issue in Mercury’s default Jupyter-backed deployment. If you run Mercury and have not explicitly enabled strong authentication, treat this as an active compromise risk and move immediately to restrict access, patch, or take the service offline until fixed.

The key issue is simple: the default “tokenless” configuration leaves a path to run arbitrary Python code through Jupyter kernels. This is not a minor bypass; it can give attackers control of the server process and access to any data, secrets, or internal services that process can reach.

Critical Vulnerabilities

CVE-2026-111058: Mercury default anonymous kernel access enables remote code execution

  • Impact: An unauthenticated attacker on the network can create a Jupyter kernel, connect to its websocket channel, and execute arbitrary Python code. That can lead to full host or container compromise, data theft, secret exposure, and lateral movement.
  • Affected Systems: pip mercury deployments, including the default tokenless configuration described in mercury_app/__main__.py. The issue is present in the release line that fixed the earlier terminal-access advisory, including Mercury 3.2.4 in default configuration.
  • Immediate Action: Assume exposure if Mercury is reachable from any untrusted network. Disable public access now, place the service behind authentication or a private network boundary, and rotate any credentials or secrets accessible to the Mercury runtime.
  • Mitigation: The current blocklist approach is insufficient because /api/kernels remains usable. Require real authentication by default, or disable anonymous kernel access entirely. If you cannot confirm a fixed build with proper auth enforcement, take the service offline until you can.

Why this matters now: This is a working unauthenticated RCE path, not a theoretical weakness. The issue survives the prior terminal-endpoint fix because kernels are still reachable and the websocket handler does not block execution requests.

Previously Alerted

What to Do Now

  1. Restrict access immediately. Remove public exposure of Mercury services and allow only trusted internal networks or VPN access.
  2. Enforce authentication. Do not rely on the default anonymous configuration. Require a real token, password, or equivalent access control before the service is reachable.
  3. Patch or disable. Upgrade to a vendor-fixed release as soon as one is available; if you cannot confirm a fix, shut the service down until you can.
  4. Assume compromise if exposed. Review process activity, unexpected files, outbound connections, and any signs of Python code execution from the Mercury server process.
  5. Rotate secrets. If the service was reachable, rotate API keys, tokens, credentials, and any other secrets the runtime could access.

Verification steps:

  • Confirm whether Mercury is internet-facing or reachable from shared internal networks.
  • Check whether the deployment is running without an explicit authentication token.
  • Validate that /api/kernels is not accessible to unauthenticated users.
  • Review logs for kernel creation, websocket connections, and unexpected notebook execution.

Monitoring recommendations:

  • Alert on new Jupyter kernels, websocket sessions, and unusual execution patterns.
  • Watch for unexpected child processes, shell commands, file writes, or outbound traffic from the Mercury runtime.
  • Increase scrutiny on containers or hosts running notebook-style services with broad filesystem or network access.

Related Resources

  • Internal: A follow-up analysis post on Mercury authentication hardening will be published separately.
  • Official vendor advisories: Monitor the Mercury project release notes and GitHub security advisories for a fixed build and deployment guidance.

Keep reading