CVE-2026-39987

What it actually does

This is a pre-authentication remote code execution vulnerability in marimo versions prior to 0.23.0. The /terminal/ws WebSocket endpoint accepts terminal connections without invoking the same authentication validation used by other WebSocket endpoints. A remote network attacker can connect directly to that endpoint and obtain an interactive PTY shell with the privileges of the marimo server process, enabling arbitrary command execution, file access, code modification, credential theft, persistence, and lateral movement from the host running the notebook service.

Why it matters to the business

An exposed vulnerable marimo instance can be fully controlled by an unauthenticated attacker, potentially leading to theft of notebooks, source code, credentials, datasets, model artifacts, and cloud tokens, as well as disruption or manipulation of research and production workflows. The vulnerability has a critical severity score, very high EPSS likelihood, is listed in CISA KEV, and is reported as actively exploited in the wild, so internet-facing deployments should be treated as urgent exposure requiring remediation by the KEV deadline of 2026-05-07 or sooner.

How an attack unfolds

An attacker first identifies a reachable marimo server, commonly by scanning for HTTP services exposing marimo-related routes. Instead of authenticating through the normal application flow, the attacker opens a WebSocket connection directly to /terminal/ws. Because vulnerable versions check only operating mode and terminal support rather than validating authentication, the connection is accepted and backed by a PTY on the server. The attacker then sends terminal input over the WebSocket to run operating system commands as the marimo process user. From there, they may enumerate the host, read notebooks and environment files, extract secrets, install tools, create persistence, pivot to adjacent systems, or modify notebooks and application code. Active exploitation has been reported, so defenders should assume attempts may already exist in web access logs, reverse proxy logs, and host process telemetry.

How to fix it

Upgrade marimo to version 0.23.0 or later, where authentication validation is enforced for the terminal WebSocket endpoint. If immediate upgrade is not possible, disable the terminal feature, block access to /terminal/ws at a reverse proxy or WAF, restrict marimo to localhost or a private network, require strong upstream authentication before any marimo route is reachable, and deny direct internet exposure. Run marimo under a dedicated low-privilege account, remove unnecessary secrets from the runtime environment, and rotate any credentials accessible to the marimo process if exposure is suspected. Because this is a KEV-listed actively exploited issue, mitigation should be considered temporary unless it fully prevents unauthenticated access to the vulnerable endpoint.

How to confirm the fix worked

Confirm the installed marimo version is 0.23.0 or later using package inventory, container image manifests, dependency lockfiles, or runtime package inspection. Test from an unauthenticated network context that a WebSocket upgrade request to /terminal/ws is rejected with an authentication or authorization failure rather than returning HTTP 101 Switching Protocols. Verify that reverse proxies, ingress controllers, WAF rules, and service exposure settings do not allow unauthenticated access to the endpoint. For containerized deployments, confirm all running images have been rebuilt with the fixed version and old pods or containers have been replaced. Review web access logs after remediation to ensure no successful unauthenticated /terminal/ws connections remain.

Typical attack path

1. Scan for exposed marimo notebook services over HTTP or HTTPS.
2. Probe WebSocket-capable routes and identify /terminal/ws as reachable.
3. Initiate a WebSocket upgrade request to /terminal/ws without valid authentication.
4. Receive an interactive terminal session because authentication is not enforced.
5. Execute shell commands with the privileges of the marimo server process.
6. Enumerate files, environment variables, notebooks, credentials, network access, and cloud metadata where available.
7. Exfiltrate data, deploy additional payloads, alter notebooks or application files, establish persistence, or use the host as a pivot point.

How to detect it

Hunt for exploitation in reverse proxy, load balancer, ingress, WAF, and application access logs by searching for WebSocket upgrade requests to /terminal/ws, especially those returning HTTP 101 or otherwise indicating an accepted connection without a prior authenticated session. Correlate those requests with source IPs, user agents, timestamps, and any absence of normal login activity. On hosts, review process telemetry for shells or command interpreters spawned by the marimo server process, Python process, container entrypoint, or notebook runtime. Look for suspicious commands commonly used after RCE, including identity checks, environment dumping, credential discovery, download-and-execute patterns, reverse shells, SSH key access, cloud metadata queries, and persistence setup. Examine filesystem artifacts such as modified notebooks, new scripts in temporary directories, unexpected cron entries, unauthorized SSH keys, newly installed binaries, and changes to startup files. In container and Kubernetes environments, review pod logs, exec-like behavior, unexpected outbound connections, mounted secret access, and image or filesystem modifications. Because exploitation is reported in the wild, include historical logs going back to the publication date if available, and at minimum cover the period before patching or endpoint blocking.

• GET /terminal/ws
• /terminal/ws
• HTTP/1.1" 101
• 101 Switching Protocols
• Upgrade: websocket
• Connection: Upgrade
• Sec-WebSocket-Key:
• Sec-WebSocket-Version: 13
• GET /terminal/ws HTTP/1.1
• python -c
• python3 -c
• bash -i
• sh -i
• /bin/bash
• /bin/sh
• /bin/zsh
• /dev/tcp/
• nc -e
• ncat -e
• curl http
• curl -O
• curl -fsSL
• wget http
• wget -O
• id;
• whoami
• uname -a
• env
• printenv
• cat /etc/passwd
• cat ~/.ssh/id_rsa
• cat ~/.ssh/authorized_keys
• 169.254.169.254
• crontab -e
• /etc/cron.d/
• /tmp/
• /var/tmp/

What your security team should do

• Immediately inventory all marimo deployments, including developer workstations, notebook servers, lab environments, containers, and externally exposed services.
• Prioritize patching or isolating any internet-accessible instance; upgrade to marimo 0.23.0 or later.
• Until patched, block /terminal/ws at the edge and restrict marimo access to trusted networks or authenticated reverse proxies only.
• Treat any successful unauthenticated WebSocket upgrade to /terminal/ws as a likely compromise and initiate incident response.
• Review process, command, file, and network telemetry on affected hosts for shell activity spawned by the marimo or Python process.
• Rotate credentials, API keys, cloud tokens, SSH keys, and database secrets that may have been present in notebooks, environment variables, configuration files, or mounted volumes.
• Apply least privilege to marimo runtime accounts and remove unnecessary write access, host mounts, cloud permissions, and network reachability.
• Use the CISA KEV status and 2026-05-07 due date to drive emergency change management and executive prioritization.