Marimo patches pre-auth RCE in terminal WebSocket

TL;DR — Marimo’s /terminal/ws endpoint can accept unauthenticated WebSocket connections and spawn a PTY shell, enabling pre-auth remote code execution on exposed instances.

What happened

Marimo is a reactive Python notebook/editor that can run as a self-hosted web service for interactive development. A GitHub-reviewed advisory describes a pre-auth RCE where the terminal WebSocket endpoint (/terminal/ws) accepts connections without performing an authentication check, then creates a PTY shell for the connected client.

The advisory notes Marimo relies on endpoint-level auth validation for WebSockets (e.g., validate_auth()), and /terminal/ws was missing this check. As a result, an attacker can connect to ws://TARGET:2718/terminal/ws and obtain an interactive shell; the advisory states commands run as root in default Docker deployments.

This is a high-impact pattern for platform teams because “auxiliary” interactive endpoints (terminal/console/debug WebSockets) are easy to miss in auth enforcement and can turn a single exposure into full host compromise.

Who is impacted

• Self-hosted Marimo deployments reachable by untrusted networks (intentional or accidental exposure of the service port).
• Environments running versions described as affected in the advisory details (marimo <= 0.20.4).
• Potentially broader scope: the advisory’s affected-range metadata indicates a fix at 0.23.0; if you operate any marimo < 0.23.0, treat it as potentially impacted until you confirm via vendor notes and your deployed behavior.
• Higher-risk deployments where the Marimo process has access to credentials (env vars), mounted volumes, or broad network egress (typical for notebook-style services).

What to do now

• Follow vendor remediation guidance and apply the latest patched release available at the time of writing (the advisory metadata marks a fix at 0.23.0).
• Restrict exposure: ensure Marimo is not internet-accessible; prefer binding to localhost or placing it behind an authenticated reverse proxy and network allowlists.
• Audit for misuse signals: review logs/telemetry for unexpected WebSocket connections to /terminal/ws and investigate any suspicious command execution.
• If compromise is suspected, rotate secrets accessible to the service (API keys, cloud credentials, database passwords) and rebuild affected environments from a known-good base.

"Add authentication validation to /terminal/ws endpoint, consistent with /ws using WebSocketConnectionValidator.validate_auth()"