Marimo Notebook Critical RCE: CVE-2026-39987 Exploited Within 10 Hours of Disclosure

The honeypot was barely online when the first connection came in. Just 9 hours and 41 minutes after the security advisory went public, an unknown attacker had already built a working exploit from the vulnerability description. Within 3 minutes, they had harvested credentials from environment files and were searching for SSH keys.

No proof-of-concept code existed. No exploit tools were available. The attacker simply read the advisory, understood the vulnerability, and connected directly to the unauthenticated terminal WebSocket endpoint.

Welcome to the new reality of vulnerability exploitation in 2026. The Marimo CVE-2026-39987 incident demonstrates how quickly modern threat actors can weaponize disclosed vulnerabilities - and why your patching window is now measured in hours, not days.

What Is Marimo and Why Does This Matter?

Marimo is a popular open-source Python reactive notebook framework with approximately 19,600 GitHub stars. Positioned as a modern alternative to Jupyter, Marimo has gained significant traction among data science teams, machine learning engineers, and internal analytics groups who value its reactive, Python-centric approach to notebook development.

The framework emphasizes features that push deployments toward internet accessibility:

• Remote sharing capabilities for collaborative work
• Interactive editing for real-time collaboration
• Container-friendly architecture for cloud deployment
• WebSocket-based architecture for responsive interfaces

These same features that make Marimo attractive for team collaboration also create security exposure. When data scientists deploy Marimo instances for remote access - often with minimal security configuration - they create high-value targets sitting adjacent to sensitive data, cloud credentials, database connections, and internal APIs.

CVE-2026-39987: The WebSocket Authentication Failure

Technical Breakdown

CVE-2026-39987 is a critical pre-authentication remote code execution vulnerability affecting all versions of Marimo prior to 0.23.0. The National Vulnerability Database assigns it a CVSS v4.0 score of 9.3 (Critical).

The vulnerability stems from inconsistent WebSocket authentication implementation across different endpoints within the Marimo server.

The Authentication Gap

Marimo exposes multiple WebSocket endpoints for different functionalities. The primary session WebSocket correctly implements authentication validation through WebSocketConnectionValidator.validate_auth(), ensuring only authorized clients maintain sessions.

However, the terminal WebSocket endpoint at /terminal/ws followed a different implementation path. According to the official security advisory, the terminal endpoint in marimo/_server/api/endpoints/terminal.py accepted connections after verifying edit mode and platform support for PTY allocation - but critically, it did not perform the same authentication validation used elsewhere.

The result: One WebSocket route was protected, while a parallel WebSocket route that provides shell access was not.

Why Middleware Failed

Marimo uses Starlette's AuthenticationMiddleware as a baseline protection layer. However, this middleware can mark connections as unauthenticated without rejecting WebSocket upgrade requests outright. Effective protection depends on endpoint-level enforcement through validate_auth() calls, decorators, or equivalent mechanisms.

The terminal WebSocket path skipped this endpoint-level enforcement. Unauthenticated clients could reach websocket.accept() and the subsequent pty.fork() path, obtaining a full interactive shell as the user running the Marimo process - often root in default Docker deployments.

Attack Chain

The exploitation sequence is remarkably simple:

1. WebSocket Connection: Attacker opens a WebSocket to ws://<host>:<port>/terminal/ws (or wss:// behind TLS)
2. Unauthenticated Acceptance: Server accepts the WebSocket without credential validation
3. PTY Allocation: Server allocates a pseudo-terminal and spawns a shell
4. Arbitrary Execution: Attacker executes commands as the Marimo process user

The advisory includes a complete proof-of-concept demonstrating this attack chain, including scenarios where the server issues access tokens for normal users - tokens that the terminal WebSocket path bypasses entirely.

Affected Versions

Important Note: While the advisory body text initially stated "Marimo <= 0.20.4" as affected, the structured version range in the affected-packages section (consumed by Dependabot, pip audit, OSV, and other tools) has been corrected to < 0.23.0. All versions prior to 0.23.0 are vulnerable.

Fixed Version

Marimo closed the authentication gap on the terminal WebSocket in version 0.23.0, aligning that path with validation used for other WebSocket endpoints.

Upgrade immediately with:

pip install --upgrade "marimo>=0.23.0"

Official advisory with full details: https://github.com/marimo-team/marimo/security/advisories/GHSA-2679-6mx9-h9xc

Exploitation in the Wild: The Speed of Modern Threat Actors

The 10-Hour Exploitation Window

CVE-2026-39987 is confirmed to be actively exploited in the wild. The Sysdig Threat Research Team deployed honeypot nodes running vulnerable Marimo instances across multiple cloud providers to monitor post-disclosure exploitation activity.

The timeline is sobering:

• **Advisory - First Exploitation Attempt: 9 hours, 41 minutes post-disclosure
• Credential Theft Operation: Completed in under 3 minutes
• Attacker Return: Reconnected after 1 hour to verify findings and check for competing threat actors

No proof-of-concept code was available when exploitation began. The attacker built a working exploit directly from the advisory description, demonstrating sophisticated technical analysis capabilities and a deep understanding of WebSocket protocols.

The Attack Pattern

Sysdig's honeypot monitoring revealed a methodical approach:

Phase 1: Initial Reconnaissance (Minutes 0-2)

• Connected to /terminal/ws WebSocket endpoint
• Manually explored the filesystem structure
• Identified user context and available commands
• Located environment files and configuration directories

Phase 2: Credential Harvesting (Minutes 2-3)

• Systematically attempted to read .env files
• Searched for SSH keys in standard locations (~/.ssh/)
• Examined configuration files for hardcoded credentials
• Read various system files to map the environment

Phase 3: Return Verification (1 hour later)

• Reconnected to access .env file contents
• Verified no competing threat actors had accessed the system
• Confirmed findings from initial session
• No additional payloads (cryptocurrency miners, backdoors, or persistence mechanisms) were installed

What This Tells Us About Modern Attackers

The Marimo exploitation demonstrates several concerning trends:

Advisory-to-Exploit Speed: Threat actors no longer need days to weaponize vulnerabilities. With clear technical descriptions, skilled attackers can develop functional exploits within hours.

Manual, Targeted Operations: Unlike automated worm propagation, this attack showed human decision-making - pausing between sessions, verifying findings, and adapting to the target environment.

Credential-Focused Objectives: The attacker prioritized credential theft over immediate monetization (no miners or ransomware). Stolen credentials enable persistent access, lateral movement, and future exploitation.

Target Scope Beyond Popularity: The assumption that attackers only target widely deployed platforms is demonstrably false. Any internet-facing application with a critical advisory becomes a target regardless of its market share.

The Hidden Exposure Problem

Underestimating Internet Footprint

Marimo's exposure is easy to underestimate because of how it's commonly deployed. Many instances run behind reverse proxies or TLS termination on standard HTTP(S) ports, making them invisible to scans targeting Marimo's default port.

Endor Labs' independent reconnaissance against large internet datasets suggests that tens or potentially hundreds of instances remain exposed and vulnerable if not patched. The actual number could be significantly higher given the prevalence of non-standard deployment configurations.

The Data Science Infrastructure Gap

This vulnerability highlights a critical security gap in data science infrastructure:

Deployment Patterns: Data science tools are often deployed for convenience rather than security:

• Quick cloud instance setups with minimal hardening
• Default Docker configurations running as root
• Exposed ports for "temporary" collaboration that becomes permanent
• Limited security review compared to production applications

Asset Visibility: Data science infrastructure often exists outside normal IT asset management:

• Shadow deployments by individual researchers
• Ephemeral cloud instances not tracked in CMDBs
• Personal API keys and credentials stored in notebooks
• Limited logging and monitoring compared to production systems

Patching Velocity: Data science environments typically patch slower than production web applications:

• Research continuity concerns delay updates
• Dependency conflicts with ML libraries
• Limited automated patching for specialized tools
• Skills gap between data science and security teams

Broader Implications: WebSocket Security in AI Tools

The Authentication Consistency Challenge

The Marimo vulnerability illustrates a fundamental WebSocket security challenge: authenticating bidirectional channels is fundamentally different from authenticating HTTP requests.

REST API Authentication:

• Short-lived request/response cycles
• Headers and cookies in familiar locations
• Middleware runs synchronously with each request
• Well-understood patterns and frameworks

WebSocket Authentication:

• Long-lived, full-duplex connections
• Identity established at upgrade time
• Easy to assume "already authenticated" from other sessions
• Framework implementations vary significantly

Different frameworks surface the WebSocket upgrade path differently, making it easy for one endpoint to accidentally skip checks that another WebSocket route applies. This is exactly the failure mode seen in Marimo - and it's a pattern likely to repeat in other applications.

The AI Tool Security Pattern

Marimo is not an isolated case. The broader category of AI-enabled development and data science tools shares common risk factors:

High-Privilege Execution: These tools often run with significant system access to perform their functions, making successful exploitation particularly damaging.

Network-Exposed by Design: Collaboration features push deployments toward internet accessibility, expanding the attack surface.

Rapid Development Cycles: Fast-moving projects may prioritize features over security review, especially for authentication edge cases.

Complex Dependency Chains: Modern AI tools depend on dozens of libraries, any of which could introduce similar authentication inconsistencies.

Detection and Response

Identifying Vulnerable Instances

Version Detection:

pip show marimo | grep Version

Any version below 0.23.0 requires immediate attention.

Network Exposure Assessment:

• Audit cloud security groups for Marimo default ports
• Review reverse proxy configurations for /terminal/ws paths
• Scan internal networks for unauthorized Marimo deployments
• Check container orchestration platforms for vulnerable images

Exploitation Indicators

Monitor for these potential compromise indicators:

WebSocket Connection Anomalies:

• Unauthenticated connections to /terminal/ws
• Terminal sessions from unexpected IP addresses
• Short-duration connections with file system access patterns

Credential Access Patterns:

• Reads of .env files or environment variables
• Access to ~/.ssh/ directories
• Configuration file reads outside normal patterns
• Cloud metadata service queries (169.254.169.254)

Post-Exploitation Activity:

• Unexpected outbound network connections
• Lateral movement attempts to internal resources
• Cryptocurrency miner installations
• Persistence mechanism deployment

Incident Response Playbook

If you suspect compromise of a Marimo instance:

Immediate Actions (First Hour):

1. Isolate the affected instance from the network
2. Capture memory dump if possible before shutdown
3. Preserve logs from the Marimo server and host
4. Rotate all credentials accessible from the instance

Investigation (Hours 1-24):

1. Analyze WebSocket access logs for /terminal/ws connections
2. Review file system access logs for unauthorized reads
3. Check for persistence mechanisms (cron jobs, systemd services)
4. Identify data that may have been accessed or exfiltrated

Recovery (Days 1-7):

1. Rebuild the instance from known-good sources
2. Upgrade to Marimo >= 0.23.0 before reconnection
3. Implement network segmentation for notebook servers
4. Review and strengthen authentication for all AI tools

Prevention and Hardening

Immediate Patching

Upgrade all Marimo installations:

pip install --upgrade "marimo>=0.23.0"

Verify the upgrade:

python -c "import marimo; print(marimo.__version__)"

Network-Level Controls

Access Restriction:

• Deploy Marimo behind VPN or zero-trust access solutions
• Implement IP allowlisting for known collaborator addresses
• Use bastion hosts for administrative access
• Never expose Marimo directly to the internet without authentication

Web Application Firewall Rules:

• Block unauthenticated WebSocket upgrade requests
• Rate limit connections to /terminal/ws
• Alert on unusual WebSocket connection patterns

Deployment Hardening

Container Security:

• Run Marimo containers as non-root users
• Implement read-only root filesystems
• Use security contexts to restrict capabilities
• Scan container images for vulnerable Marimo versions

Credential Management:

• Never store credentials in notebook files or environment variables
• Use secret management solutions (HashiCorp Vault, AWS Secrets Manager)
• Implement short-lived credentials with automatic rotation
• Audit notebook files for accidentally committed secrets

Monitoring and Alerting

WebSocket Monitoring:

• Log all WebSocket connections with authentication status
• Alert on terminal endpoint access without prior session authentication
• Monitor for unusual connection durations or data volumes

File System Monitoring:

• Audit access to sensitive files (/etc/passwd, .env, SSH keys)
• Alert on reads of cloud metadata services
• Monitor for credential file access outside normal patterns

FAQ: Marimo CVE-2026-39987

How severe is CVE-2026-39987?

CVE-2026-39987 has a CVSS v4.0 score of 9.3 (Critical). It allows pre-authentication remote code execution, meaning attackers can gain complete control of affected systems without any credentials. The vulnerability is actively exploited in the wild, with exploitation observed within 10 hours of disclosure.

Which Marimo versions are affected?

All versions prior to 0.23.0 are vulnerable. While the initial advisory mentioned versions <= 0.20.4, the corrected version range includes all versions before 0.23.0. You must upgrade to 0.23.0 or later to be protected.

How do I check if my Marimo instance is vulnerable?

Run the following command to check your version:

pip show marimo | grep Version

If the version is below 0.23.0, you are vulnerable and should upgrade immediately.

Is there evidence of active exploitation?

Yes. Sysdig's Threat Research Team confirmed exploitation within 9 hours and 41 minutes of the advisory publication. The attacker performed credential theft operations and returned to verify findings, indicating targeted, human-operated attacks rather than automated scanning.

Can I mitigate this without upgrading?

No reliable mitigation exists without upgrading. While you could block access to /terminal/ws at the reverse proxy level, this may break legitimate functionality and does not address the underlying vulnerability. Upgrade to 0.23.0 is strongly recommended.

How does the attack work?

The attack exploits inconsistent WebSocket authentication. While Marimo's primary session WebSocket requires authentication, the terminal WebSocket endpoint at /terminal/ws does not validate credentials. Attackers connect to this endpoint and receive a full interactive shell without providing any authentication.

What data is at risk?

Successful exploitation grants attackers shell access as the Marimo process user. This typically provides access to:

• Environment variables and .env files containing credentials
• SSH keys for lateral movement
• Cloud metadata and instance credentials
• Database connection strings
• Source code and proprietary algorithms
• Any data accessible to the Marimo process

Should I assume compromise if I ran a vulnerable version?

If your Marimo instance was internet-accessible while running a vulnerable version, you should assume potential compromise. Review logs for connections to /terminal/ws, rotate all credentials accessible from the instance, and consider rebuilding from known-good sources.

How can I detect if my instance was compromised?

Review these logs for indicators:

• WebSocket access logs showing /terminal/ws connections
• File system access logs for .env, SSH keys, or cloud metadata
• Process execution logs for unexpected commands
• Network connection logs for unusual outbound traffic

What's the difference between Marimo and Jupyter security?

Both notebook platforms face similar security challenges when exposed to networks. Jupyter has historically had its own authentication vulnerabilities (CVE-2023-39968, CVE-2023-40170). The key lesson applies to both: notebook servers should never be exposed to untrusted networks without robust authentication and network controls.

Are other AI development tools vulnerable to similar issues?

Yes. The pattern of inconsistent authentication across WebSocket endpoints is not unique to Marimo. Any AI tool using WebSocket connections for real-time features should be audited for similar authentication gaps, especially tools with terminal or code execution capabilities.

How should I secure Marimo for team collaboration?

Secure deployment requires:

1. Upgrade to version 0.23.0 or later
2. Deploy behind a VPN or zero-trust access solution
3. Implement IP allowlisting where possible
4. Run as non-root user in containers
5. Use external secret management instead of environment variables
6. Enable comprehensive logging and monitoring
7. Regular security scanning for vulnerable dependencies

The Bigger Picture: AI Tool Security in 2026

The Convergence of Convenience and Risk

The Marimo vulnerability exemplifies a broader trend in AI tooling: the features that make these tools powerful and convenient also make them dangerous when exposed. Real-time collaboration, interactive terminals, and seamless cloud integration are double-edged swords.

As AI tools proliferate across enterprises, security teams face an expanding attack surface that often exists outside traditional IT governance. Data science teams deploy tools for legitimate business needs, but without security review, these deployments become invisible risks.

The Patching Velocity Gap

The 10-hour exploitation window for Marimo highlights a critical gap in enterprise security operations. Traditional patching cycles measured in weeks or months are no longer viable when attackers can weaponize vulnerabilities within hours.

Organizations need:

• Automated vulnerability scanning for AI tools
• Rapid patching workflows for critical CVEs
• Network segmentation to contain vulnerable instances
• Threat intelligence integration for emerging AI tool vulnerabilities

The Human Element

Despite the technical sophistication of the Marimo vulnerability, the exploitation pattern was fundamentally human. The attacker read the advisory, understood the implications, and manually targeted the vulnerable endpoint. This wasn't a worm or automated exploit kit - it was a skilled operator making decisions.

This human element means detection and response must account for adaptive adversaries who can adjust tactics based on target environment and defensive measures.

Conclusion: Treat Notebook Servers as High-Value Targets

CVE-2026-39987 is a wake-up call for any organization using Marimo or similar notebook platforms. These tools often sit adjacent to the most sensitive data in your enterprise - customer records, proprietary algorithms, cloud credentials, and database connections - yet they're frequently deployed with minimal security consideration.

The speed of exploitation - 10 hours from disclosure to active credential theft - demonstrates that your patching window is now measured in hours, not days. If you run Marimo in edit mode anywhere it could be reached beyond a tightly trusted network, you must upgrade immediately.

Beyond patching, this incident highlights the need for fundamental security architecture changes:

Treat notebook servers as high-value targets because they are. The data they access makes them attractive to attackers, and their execution capabilities make them dangerous when compromised.

Implement consistent authentication across all endpoints, especially WebSocket connections that provide shell access or code execution capabilities.

Deploy defense in depth with network segmentation, monitoring, and least-privilege execution limiting the impact of any single vulnerability.

Close the data science security gap by bringing these deployments under IT security governance without blocking legitimate research needs.

The attacker who exploited Marimo within 10 hours of disclosure didn't use sophisticated zero-day techniques or nation-state tools. They simply read the advisory, understood the vulnerability, and connected to an unauthenticated endpoint.

Sometimes the most dangerous attacks are the simplest ones.

If you run Marimo, upgrade to 0.23.0 today. Your next 10 hours start now.

---

Stay ahead of emerging AI security threats. Subscribe to the Hexon.bot newsletter for weekly vulnerability intelligence and defense strategies.