marimo is a reactive Python notebook

CVE-2026-39987 is a missing-authentication flaw in marimo's terminal WebSocket endpoint, /terminal/ws, letting a remote attacker get an interactive shell without credentials. Authoritative sources put the affected range at versions before 0.23.0; the vendor release notes further narrow practical exposure to editable notebook deployments that are network-reachable, especially marimo edit --host 0.0.0.0, not app/run mode.

In pure technical terms the vendor's *critical* label is fair: this is pre-auth remote code execution with no user interaction. In fleet reality, severity comes down a notch because the vulnerable population is a subset of marimo installs: you need marimo deployed in edit mode, reachable over a network, and not fronted by stronger external auth. KEV listing and confirmed exploitation slam the brakes on any further downgrade, so this stays HIGH for enterprise patching priority.

Why this verdict

• Downgrade for reachability friction: the attacker needs a network-reachable marimo server in edit mode; app/run mode is explicitly out of scope, which cuts the exposed population hard.
• Downgrade for exposure population: marimo is a niche developer/data-science platform, not a ubiquitous enterprise control plane; many 10,000-host environments will have zero or very few installs.
• Downgrade for control assumptions: if the notebook is behind VPN, SSO proxy, private ingress, or segmentation, the unauthenticated remote precondition disappears.
• Upgrade back up for exploitation reality: CISA KEV plus exploitation in under 10 hours means exposed instances are not waiting for a sophisticated actor; they're already in commodity-attack territory.
• Upgrade back up for blast radius: notebook hosts routinely sit near cloud keys, SSH material, databases, and model assets, so one shell often turns into broader environment access.

Why not higher?

I am not calling this CRITICAL for fleet prioritization because the raw CVSS assumes universal reachability that simply is not true here. The exploit chain starts with a big environmental qualifier: exposed, editable marimo notebooks. In a normal enterprise, that is a much smaller slice than 'all hosts running vulnerable software.'

Why not lower?

I am not pushing this down to MEDIUM because the bug is still unauthenticated remote shell on exposed targets, with KEV listing and confirmed exploitation. Once the preconditions are met, there is very little attacker friction left and the post-exploitation value is unusually high for data-science infrastructure.

1. Pull edit-mode marimo off reachable networks — Move any marimo edit deployment behind VPN, private ingress, or a bastion immediately; if it is internet-facing, treat it as an emergency and do this within hours because KEV/active exploitation override the normal HIGH timeline.
2. Disable or block WebSocket access to /terminal/ws — At the reverse proxy, ingress controller, or firewall layer, explicitly block the terminal WebSocket path until all instances are upgraded. This is the most direct compensating control and should be deployed within hours on exposed systems.
3. Force external auth in front of notebook editors — Put editable notebook access behind SSO, access proxy, or identity-aware proxy rather than relying on built-in app auth alone. Deploy this within hours for exposed services, and complete coverage well inside the normal 30-day HIGH mitigation window elsewhere.
4. Hunt for secret access and child-process execution — Review runtime telemetry for shell spawns from marimo/Python, reads of .env or ~/.ssh, and unusual outbound traffic from notebook hosts. Because exploitation is confirmed, start hunting immediately on any host that was exposed after 2026-04-08.
5. Rotate co-located credentials — If a vulnerable exposed instance existed at any time after disclosure, rotate cloud keys, SSH keys, database passwords, and API tokens reachable from that host. Do this within hours for exposed instances because attacker dwell time in observed cases was measured in minutes.

Run this on the target Linux host or container that may be serving marimo, not from an auditor workstation. Invoke with sudo bash ./check_marimo_cve_2026_39987.sh or bash ./check_marimo_cve_2026_39987.sh if you already have permission to inspect processes; it needs local process visibility and benefits from root for full command-line inspection.

#!/usr/bin/env bash
# check_marimo_cve_2026_39987.sh
# Detects likely exposure to CVE-2026-39987 on Linux hosts.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

have_cmd() { command -v "$1" >/dev/null 2>&1; }

verlt() {
  # returns 0 if $1 < $2 using sort -V
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && [ "$1" != "$2" ]
}

VERSION=""
SOURCE=""

# Try Python import first
for py in python3 python; do
  if have_cmd "$py"; then
    VERSION="$($py - <<'PY' 2>/dev/null
try:
    import marimo
    print(getattr(marimo, '__version__', ''))
except Exception:
    pass
PY
)"
    if [ -n "$VERSION" ]; then
      SOURCE="python-import:$py"
      break
    fi
  fi
done

# Fallback to pip metadata
if [ -z "$VERSION" ]; then
  for pipcmd in "python3 -m pip" "python -m pip" pip3 pip; do
    if sh -c "$pipcmd --version" >/dev/null 2>&1; then
      VERSION="$(sh -c "$pipcmd show marimo 2>/dev/null | awk -F': ' '/^Version:/{print \$2; exit}'")"
      if [ -n "$VERSION" ]; then
        SOURCE="pip-show:$pipcmd"
        break
      fi
    fi
  done
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - marimo package version not found"
  exit 2
fi

# Determine if version is fixed
if verlt "$VERSION" "0.23.0"; then
  PKG_STATE="vulnerable"
else
  echo "PATCHED - marimo version $VERSION ($SOURCE) is >= 0.23.0"
  exit 0
fi

# Inspect processes for risky runtime posture
RISKY_PROC=0
RISKY_DETAILS=""
if have_cmd ps; then
  while IFS= read -r line; do
    cmd="$line"
    echo "$cmd" | grep -E '(^|[ /])marimo([ ]|$)' >/dev/null 2>&1 || continue
    echo "$cmd" | grep -E '([ ]|^)edit([ ]|$)|marimo[ ]+edit' >/dev/null 2>&1 || continue
    if echo "$cmd" | grep -E -- '--host[ =](0\.0\.0\.0|::)| -h[ ]+(0\.0\.0\.0|::)' >/dev/null 2>&1; then
      RISKY_PROC=1
      RISKY_DETAILS="$RISKY_DETAILS\n$cmd"
    elif ! echo "$cmd" | grep -E -- '--host[ =](127\.0\.0\.1|localhost)| -h[ ]+(127\.0\.0\.1|localhost)' >/dev/null 2>&1; then
      # No explicit localhost binding seen; still suspicious for edit mode
      RISKY_PROC=1
      RISKY_DETAILS="$RISKY_DETAILS\n$cmd"
    fi
  done < <(ps -eo args= 2>/dev/null)
fi

# Inspect listening sockets on the common marimo port if possible
PORT2718=0
if have_cmd ss; then
  ss -lntp 2>/dev/null | grep -E '[:.]2718[[:space:]]' >/dev/null 2>&1 && PORT2718=1
elif have_cmd netstat; then
  netstat -lntp 2>/dev/null | grep -E '[:.]2718[[:space:]]' >/dev/null 2>&1 && PORT2718=1
fi

if [ "$RISKY_PROC" -eq 1 ]; then
  echo "VULNERABLE - marimo version $VERSION (<0.23.0) with likely exposed edit-mode process detected.${RISKY_DETAILS}"
  exit 1
fi

if [ "$PORT2718" -eq 1 ]; then
  echo "VULNERABLE - marimo version $VERSION (<0.23.0); listening on common marimo port 2718, exposure should be reviewed immediately"
  exit 1
fi

echo "UNKNOWN - marimo version $VERSION is vulnerable (<0.23.0), but this script could not confirm an exposed edit-mode runtime. Review running processes, ingress, and reverse-proxy paths manually."
exit 2

Sources

1. NVD CVE-2026-39987
2. GitHub Advisory GHSA-2679-6mx9-h9xc
3. marimo 0.23.0 release notes
4. marimo PR #9098 fix: properly authenticate terminal route
5. Sysdig: From disclosure to exploitation in under 10 hours
6. Sysdig: weaponized for blockchain botnet via Hugging Face
7. Endor Labs: Root in One Request
8. ProjectDiscovery nuclei templates release