CVE-2026-39987 puts exposed Marimo notebooks on a fast credential-theft path

CVE-2026-39987 puts exposed Marimo notebooks on a fast credential-theft path

CVE-2026-39987 is a sharp reminder that smaller developer and data-science platforms now sit in the same emergency lane as better-known internet-facing tools. In affected Marimo versions, the /terminal/ws endpoint could accept unauthenticated WebSocket connections and hand attackers a live shell. That turns a single vulnerability disclosure into a direct exploit path.

The urgency is not theoretical. Sysdig said it observed the first exploitation attempt less than 10 hours after the advisory went public, followed by manual reconnaissance and theft of .env contents from exposed instances. For defenders, that means exposed notebook environments should be treated as credential-rich application infrastructure, not harmless internal tooling.

What Marimo disclosed

GitHub’s advisory for Marimo says versions 0.20.4 and earlier are affected. The root issue is missing authentication enforcement on the terminal WebSocket endpoint. While Marimo’s other WebSocket flows validate auth, /terminal/ws skipped that check and could grant an interactive PTY shell to any remote client that could connect.

NVD describes the issue as CWE-306: Missing Authentication for Critical Function and lists the fix in Marimo 0.23.0. In practical terms, an attacker does not need to steal a session first, trick a user, or chain together multiple bugs. If the vulnerable service is reachable and running in edit mode, the attack surface is already dangerously short.

Why this matters more than a niche-tool bug

It is easy to underestimate a project like Marimo because it is not as widely deployed as some other notebook or AI workflow platforms. That is the wrong lesson.

The real story is speed. Sysdig said an operator turned the advisory into working exploitation in 9 hours and 41 minutes, then used the shell to inspect the environment, read .env, and probe for SSH material. That pattern matters because notebook platforms often sit close to cloud credentials, API keys, service secrets, and development data.

Once attackers land in that kind of environment, the first objective is rarely persistence. It is usually access to high-value secrets that enable lateral movement into cloud accounts, databases, CI systems, or internal applications.

What the observed exploitation tells defenders

According to Sysdig’s observations, the operator workflow was simple and disciplined:

• confirm code execution through the terminal WebSocket
• run basic environment discovery commands like pwd, whoami, and ls
• read the .env file for credentials and secrets
• probe for SSH-related locations and other useful files
• return later to validate access again

That is important because it shows how little friction the attacker faced. This was not noisy commodity malware spraying random payloads. It was hands-on-keyboard credential harvesting against exposed workloads.

For defenders, that means the immediate risk is not only remote code execution. It is also rapid credential exposure, downstream incident response work, and the possibility that one exposed notebook becomes an entry point to a broader environment.

What security teams should do now

Patch and verify exposure immediately

• Upgrade Marimo to 0.23.0 or later.
• Identify every instance running in editable mode or bound to 0.0.0.0.
• Confirm that development notebooks, shared research environments, and temporary demo deployments are not still exposed.

Treat exposed instances as potentially compromised

• Review access logs and WebSocket activity around /terminal/ws.
• Check for unusual shell activity, reads of .env, and file access around SSH locations.
• Rotate any secrets that may have been reachable from the notebook environment, especially cloud credentials, API tokens, and service passwords.

Reduce the blast radius

• Move notebook access behind tightly controlled access control paths such as VPN or zero-trust access brokers.
• Keep notebook and research environments segmented from broader production assets with strong network segmentation.
• Avoid running these platforms with more privileges than required, especially in containerized or cloud-connected deployments.

Strategic takeaway

CVE-2026-39987 is another sign that advisory-to-exploitation time has collapsed for exposed application platforms. Attackers no longer need a polished public proof of concept to move fast. If the advisory names the endpoint, describes the missing check, and the target holds useful secrets, that can be enough.

For defenders, the lesson is straightforward: internet-facing notebook tooling belongs in the same patch, exposure, and secret-rotation discipline as other high-risk admin and developer services. If Marimo was reachable from untrusted networks, the question is no longer just whether you patched it. The question is whether you also verified what secrets may already have been exposed.

What is CVE-2026-39987?

It is a pre-authentication remote code execution flaw in Marimo where the /terminal/ws endpoint can grant an unauthenticated interactive shell.

Which versions are affected?

Public advisories say Marimo 0.20.4 and earlier are affected, and the issue is fixed in 0.23.0.

Is it being exploited in the wild?

Yes. Sysdig reported exploitation activity in under 10 hours after the advisory was published, including .env theft and SSH-key hunting on exposed instances.

Why is this especially dangerous?

Because notebook platforms often contain cloud credentials, service secrets, and developer context that can support follow-on compromise after the initial shell access.

References

1. GitHub Advisory GHSA-2679-6mx9-h9xc: Pre-Auth Remote Code Execution via Terminal WebSocket Authentication Bypass
2. NVD: CVE-2026-39987
3. Sysdig: Marimo OSS Python Notebook RCE, From Disclosure to Exploitation in Under 10 Hours
4. BleepingComputer: Critical Marimo pre-auth RCE flaw now under active exploitation