CVE-2026-39987: Marimo RCE Flaw Exploited Within Hours

A single WebSocket handshake. No username, no password, no token. That’s all it took to get a full interactive shell on thousands of Marimo notebook instances running across cloud GPU platforms, Docker containers, and shared research servers. CVE-2026-39987 is the kind of bug that makes you rethink how AI development tools get deployed — because the gap between “advisory published” and “credentials stolen” was measured in hours, not weeks.

The Vulnerability: One Endpoint, Zero Authentication

#

Marimo is a reactive Python notebook with roughly 19,600 GitHub stars — popular among ML engineers and data scientists who prefer its reproducibility model over traditional Jupyter workflows. The vulnerability, discovered by the Sysdig Threat Research Team, sits in the /terminal/ws WebSocket endpoint.

Here’s what went wrong: Marimo’s primary notebook WebSocket at /ws properly enforced authentication through a validate_auth() call. The terminal endpoint, however, only checked whether the server was in the right running mode and whether the platform supported terminal access. It never called validate_auth(). The AuthenticationMiddleware sitting in front of both endpoints wasn’t granular enough to catch the gap — it didn’t enforce per-endpoint authentication, and the terminal endpoint simply slipped through.

The result? A single unauthenticated WebSocket connection hands back a fully interactive PTY shell running as whatever user owns the Marimo process. In Docker containers — which is how a significant chunk of Marimo deployments run — that user is often root.

Assigned CWE-306 (Missing Authentication for Critical Function) and a CVSS v4.0 score of 9.3, the flaw affects every Marimo version through 0.20.4. The patch landed in version 0.23.0 via PR #9098.

From Disclosure to Exploitation: 9 Hours 41 Minutes

#

The advisory dropped on April 8, 2026. Less than 10 hours later, Sysdig observed the first in-the-wild exploitation — and no public proof-of-concept code existed yet. The attackers had apparently diffed the patch, identified the missing auth check, and built their own exploit.

This timeline isn’t unprecedented for AI toolchain vulnerabilities, but it’s tightening. Langflow’s CVE-2026-33017 saw working exploits within 20 hours. The Flowise CVE-2025-59528 RCE flaw had a CVSS 10.0 and attracted rapid exploitation too. The pattern is clear: AI development tools are now prime targets, and the window between disclosure and active exploitation is shrinking to single-digit hours.

What stands out about the Marimo exploitation is that it was a human operator, not automated tooling. Sysdig tracked 4 connections over a 90-minute session — someone manually navigating the filesystem, poking around directories, reading files. This wasn’t a spray-and-pray botnet. It was targeted, deliberate reconnaissance.

What the Attackers Were After

#

The post-exploitation behavior tells you everything about the attacker’s objectives. Within minutes of gaining shell access, they went straight for:

• .env files — the go-to location for API keys, database connection strings, and service credentials
• Shell history files — .bash_history, .zsh_history — which often contain credentials passed as command-line arguments
• Cloud SDK configuration — AWS credentials in ~/.aws/, GCP service account keys, Azure CLI tokens
• LLM API keys — OpenAI, Anthropic, and other provider keys that can run up five-figure bills in days

Credential theft was completed in under 3 minutes per target. No malware was dropped, no persistence mechanisms were installed. Grab the keys, get out. This is a smash-and-grab operation optimized for stealing cloud credentials and LLM API access — assets that can be monetized immediately through resale or abuse of AI services.

The simplicity here is the scary part. There’s no exploit chain, no memory corruption, no shellcode. You connect to a WebSocket and you’re in. The attack complexity rating is “low” for good reason.

The Blast Radius: Who’s Exposed

#

Marimo isn’t a niche tool. According to the Cloud Security Alliance’s research note, notable adopters include Stanford, Mozilla AI, OpenAI, and BlackRock. The deployment surface spans Docker containers, GPU cloud instances provisioned through tools like SkyPilot, Hugging Face Spaces, and CoreWeave clusters.

An Endor Labs survey found 186 internet-reachable Marimo instances, of which 30 (about 16%) accepted unauthenticated WebSocket handshakes. That’s the directly scannable surface. The real exposure is larger when you count instances behind VPNs that still lack internal authentication, shared GPU servers in research labs, and ephemeral cloud instances that spun up from vulnerable base images.

The deployment pattern makes this worse than a typical web app vulnerability. AI notebooks run with access to training data, model weights, cloud storage buckets, and a constellation of API keys. Compromising one notebook instance can cascade into access across an organization’s entire ML infrastructure. A stolen AWS credential from a data scientist’s notebook doesn’t just give you their S3 bucket — it gives you whatever IAM permissions that role carries, which in research environments tends to be far more than necessary.

Why AI Toolchains Keep Getting Hit

#

This vulnerability isn’t an isolated incident. It’s part of a pattern that’s been accelerating through 2025 and into 2026. AI development tools — notebooks, agent frameworks, model serving platforms — were built for experimentation speed, not adversarial environments. The security model often assumes the tool runs locally or behind a trusted network boundary.

That assumption broke years ago. Teams deploy notebooks on cloud GPUs for training runs. They expose agent platforms to integrate with external services. They share instances across research groups for collaboration. The tools haven’t caught up to how they’re actually used.

A few specific problems keep recurring:

• Inconsistent authentication enforcement — exactly what happened here. Some endpoints get auth, others don’t. Middleware-level auth isn’t enough when individual endpoints can opt out.
• Overprivileged execution contexts — running as root in containers, broad IAM roles, API keys with full account access stored in plaintext.
• No network segmentation — notebook ports exposed directly to the internet with no WAF, no IP allowlisting, no VPN requirement.
• Slow patch adoption — research teams don’t have the same patch management discipline as production engineering teams. A vulnerable Marimo version might run for months on a shared GPU server that nobody owns.

The OpenClaw marketplace incident showed similar problems at the agent layer. The entire AI development stack, from notebooks to agent frameworks to model registries, needs the same security scrutiny that web application frameworks received a decade ago.

Remediation: What to Do Right Now

#

If your organization runs Marimo in any capacity, here’s the priority list:

1. Upgrade to Marimo 0.23.0 or later — this patches the /terminal/ws authentication bypass directly.
2. Rotate every credential accessible from Marimo instances — AWS keys, GCP service accounts, LLM API keys, database passwords, anything in .env files or cloud SDK configs. Assume compromise if you were running an exposed instance after April 8.
3. Audit WebSocket logs — look for connections to /terminal/ws after April 8, 2026. Any unauthenticated connections to that endpoint are suspect.
4. Restrict network access to port 2718 — Marimo’s default port should never be directly internet-reachable. Put it behind a VPN, bastion host, or at minimum an IP allowlist.
5. Review container privileges — if Marimo runs in Docker, ensure it’s not running as root. Use a non-root user, drop capabilities, and mount volumes read-only where possible.
6. Implement credential management — stop storing API keys in .env files on notebook instances. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) and inject credentials at runtime with short-lived tokens.

For teams using other AI development tools, this is a good time to audit your entire notebook and agent infrastructure. Check whether endpoints enforce authentication consistently, whether execution contexts follow least-privilege principles, and whether your network architecture actually prevents unauthorized access.

Key Takeaways

#

1. CVE-2026-39987 gave unauthenticated attackers full shell access on Marimo notebooks through a single WebSocket connection — no exploit chain required.
2. Exploitation began 9 hours 41 minutes after disclosure, with credential theft completed in under 3 minutes per target, demonstrating how fast the window closes for patching AI tools.
3. The attackers specifically targeted cloud credentials, LLM API keys, and service tokens — assets that can be monetized immediately and cascade into broader infrastructure compromise.
4. AI development tools consistently suffer from inconsistent authentication, overprivileged execution contexts, and deployment patterns that expose them beyond their intended trust boundaries.
5. Organizations running any AI notebook or agent platform should treat network isolation, credential management, and patch velocity with the same urgency as production web applications.

Frequently Asked Questions

#

What is CVE-2026-39987 and how does it affect Marimo notebooks?

#

CVE-2026-39987 is a critical pre-authentication remote code execution vulnerability in Marimo, a reactive Python notebook. The /terminal/ws WebSocket endpoint skipped authentication checks entirely, allowing anyone to open an interactive shell without credentials.

Which Marimo versions are vulnerable to CVE-2026-39987?

#

All Marimo versions through 0.20.4 are affected. The fix was released in version 0.23.0 via pull request #9098. Organizations should upgrade immediately and rotate any credentials that may have been accessible.

How quickly was CVE-2026-39987 exploited in the wild?

#

Sysdig detected the first in-the-wild exploitation just 9 hours and 41 minutes after the advisory was published. No public proof-of-concept existed at that point — attackers reverse-engineered the fix independently.

What should organizations do if they were running an exposed Marimo instance?

#

Assume credentials have been compromised. Upgrade to Marimo 0.23.0 immediately, rotate all API keys and cloud credentials accessible from the instance, audit WebSocket logs for unauthorized /terminal/ws connections after April 8, and restrict network access to the Marimo port behind a VPN or firewall.

Sources & References

#

• The Hacker News — Marimo RCE Flaw CVE-2026-39987 — primary reporting on the vulnerability details, exploitation timeline, and Sysdig’s observations of in-the-wild attack behavior
• Cloud Security Alliance — CSA Research Note on Marimo RCE — analysis of affected deployment surfaces, notable adopters, and comparison to related AI toolchain CVEs
• Endor Labs — Root in One Request: Marimo’s Critical Pre-Auth RCE — technical root cause analysis, internet exposure sampling data, and remediation guidance