Marimo RCE Exploited 10 Hours After Disclosure—CISA Adds to KEV

A critical vulnerability in Marimo, the increasingly popular open-source Python notebook platform, was exploited in the wild less than 10 hours after public disclosure. The speed of weaponization underscores how quickly attackers operationalize new vulnerabilities—particularly those affecting developer tooling.

CVE-2026-39987 carries a CVSS score of 9.3 and affects all Marimo versions through 0.20.4. CISA added the flaw to its Known Exploited Vulnerabilities catalog with a remediation deadline of April 11, 2026—today.

What Makes This Vulnerability So Dangerous?

The flaw resides in Marimo's terminal WebSocket endpoint at /terminal/ws. Unlike other WebSocket endpoints in the application that properly call authentication validation functions, this endpoint skips authentication entirely. It checks only whether the server is in the correct running mode and whether the platform supports the feature before accepting connections.

The result: any attacker who can reach an exposed Marimo instance gets a full PTY shell without credentials. No authentication bypass required—authentication simply doesn't exist for this endpoint.

This pattern of missing authentication on sensitive endpoints has become distressingly common. We saw something similar with the PraisonAI sandbox escape vulnerability last week, where exception handling bypasses allowed code execution. Developer tools often prioritize usability over security, and the assumptions made during development don't survive contact with internet-exposed deployments.

Exploitation Timeline

The vulnerability disclosure-to-exploitation timeline was brutal:

• Hour 0: Advisory published
• Hour 9.7: First confirmed exploitation attempt observed
• No PoC existed: Attackers built working exploits directly from the advisory text

Endor Labs research documented the attack patterns. The threat actor connected multiple times over a 90-minute window, pausing between sessions—behavior consistent with manual targeting rather than automated spray-and-pray scanning. Within minutes of gaining shell access, the attacker systematically explored the filesystem, hunting for .env files, SSH keys, and cloud credentials.

Who's Running Exposed Marimo Instances?

Marimo markets itself as a reactive Python notebook that's "better than Jupyter." It's gained traction among data scientists and ML engineers for its clean interface and reproducible execution model. But many users deploy it without considering network exposure.

The attack surface is substantial. Marimo instances are commonly found in:

• Development environments with relaxed security controls
• ML training pipelines where data scientists need remote access
• Internal tools that get accidentally exposed via misconfigured cloud deployments
• Docker containers running with default configurations

If you're running Marimo—especially in any environment with network access beyond localhost—assume you need to patch immediately.

How to Protect Your Environment

Immediate actions:

1. Upgrade to version 0.23.0 - This release patches the authentication bypass
2. Audit network exposure - Marimo should never be directly internet-accessible
3. Review access logs - Look for unexpected WebSocket connections to /terminal/ws
4. Check for artifacts - If compromised, attackers likely dropped persistence mechanisms

Detection indicators:

• WebSocket connections to /terminal/ws from unexpected sources
• Shell commands executed through the Marimo process
• File access patterns targeting credential stores (.env, .aws, .ssh)

The Larger Pattern

This incident fits a concerning trend we've been tracking. AI and ML tooling—n8n workflow platforms, AI agent frameworks, and now Python notebooks—increasingly ship with security gaps that become critical when deployed in production.

The 10-hour exploitation window also matches what CYFIRMA researchers documented in their infostealer-to-ransomware pipeline analysis. Threat actors have dramatically shortened the time from vulnerability disclosure to active exploitation. The old assumption that you have weeks or months to patch after a CVE drops is no longer valid.

Why This Matters

Developer tooling vulnerabilities are particularly dangerous because they provide access to:

• Source code repositories
• API keys and service credentials
• Database connection strings
• Cloud provider access tokens

A compromised development environment isn't just a single machine—it's often a gateway to production infrastructure. The attacker who shells your data scientist's Marimo instance may be one .env file away from your production databases.

Organizations should treat developer tools with the same security rigor applied to production systems. Network segmentation, authentication requirements, and access logging aren't optional when the tool provides shell access.

Patch today. The deadline isn't arbitrary—it reflects how quickly this vulnerability moved from disclosure to active exploitation.