A critical vulnerability in the popular open-source data notebook Marimo has highlighted how quickly attackers now weaponize newly disclosed security issues. According to telemetry from Sysdig, the first real-world exploitation attempt of CVE-2026-39987 was observed less than 10 hours after the public advisory was released.
CVE-2026-39987 in Marimo: Unauthenticated Remote Code Execution via WebSocket
The vulnerability CVE-2026-39987 is rated CVSS 9.3 and affects all Marimo versions up to and including 0.20.4. The issue is resolved in version 0.23.0, making an upgrade to this release or later a critical priority for any organization running Marimo.
The root cause is a missing authentication check on the WebSocket endpoint /terminal/ws. While other WebSocket routes (such as /ws) correctly invoke the validate_auth() function, /terminal/ws only verifies runtime mode and platform support and completely skips user validation.
As a result, a remote, unauthenticated attacker can establish a WebSocket connection to the terminal endpoint and obtain a fully interactive PTY shell on the server. In practical terms, any internet-exposed, vulnerable Marimo instance effectively grants shell-level remote access without credentials, similar in impact to an unsecured SSH service.
Honeypot Evidence: Exploitation of Marimo RCE in Under 10 Hours
To study real-world attacker behavior, Sysdig deployed a deliberately vulnerable Marimo instance as a honeypot. The first confirmed exploitation attempt occurred just 9 hours and 41 minutes after the vulnerability was publicly disclosed, at a time when no ready-made public proof-of-concept (PoC) exploit was yet available.
An unknown operator connected directly to the /terminal/ws WebSocket endpoint, gained shell access, and began manual reconnaissance. The attacker browsed the file system, examined directory structures, and searched for potentially sensitive information. Within minutes, they systematically attempted to read the .env file, locate SSH keys, and access other files likely to contain credentials or secrets.
Roughly an hour later, the same attacker returned, reconnected to the terminal, and checked whether any other actors had interacted with the honeypot in the meantime. They again targeted the contents of .env. Notably, Sysdig did not observe deployment of cryptocurrency miners, backdoors, or other noisy payloads. The activity was tightly focused on credential and secret theft, which often serves as a stepping stone for further lateral movement.
Over a 90-minute window, the adversary established four separate terminal sessions, pausing between them. This pattern is characteristic of a human operator working through a queue of targets and periodically returning to verify results, rather than fully automated scanning.
From Disclosure to Exploit: The Patch Window Is Now Measured in Hours
The fact that the attacker was able to craft a working exploit solely from the official advisory text, without relying on a published PoC, underscores a broader industry trend. For experienced threat actors, a minimal technical description is often sufficient to rapidly reverse-engineer a bug and weaponize it.
Multiple security vendors have reported that the median time between disclosure of a critical vulnerability and the onset of widespread exploitation has shrunk from weeks or days to, increasingly, a matter of hours. At the same time, many organizations still operate patch management and change-control processes that take days or longer, leaving a significant exposure window.
Why Niche Open-Source Tools Like Marimo Are High-Value Targets
The Marimo incident challenges the assumption that attackers focus only on the largest and most widely deployed platforms. In practice, any internet-accessible application tied to a public critical advisory becomes an attractive target, regardless of its market share or brand recognition.
Tools such as data notebooks are frequently deployed in research environments, analytics labs, and DevOps infrastructure. On those same servers, organizations often store cloud access keys, CI/CD tokens, database passwords, and other high-value secrets. Compromising even a single “sidecar” service may therefore enable a broad escalation of an attack across cloud accounts, pipelines, and production systems.
Security Recommendations for Marimo Administrators and DevOps Teams
1. Immediate upgrade. All Marimo users should upgrade as soon as possible to version 0.23.0 or later. It is essential to confirm that outdated containers and images are not still running in test, lab, or auxiliary environments, which are often overlooked yet accessible from the internet.
2. Restrict network exposure. Marimo instances should not be directly reachable from the public internet unless strictly required. Place the service behind a reverse proxy, enforce access via VPN, use IP allowlists, and integrate robust authentication mechanisms (such as SSO, OAuth, or corporate identity providers).
3. Minimize the attack surface. If the terminal functionality is not needed, disable it or restrict it to administrators only. Administrative WebSocket endpoints in particular should be shielded from external networks and treated as high-risk interfaces.
4. Protect secrets properly. The honeypot data shows that .env files and SSH keys were primary targets. Sensitive data should be stored in dedicated secret-management systems (such as Vault or cloud KMS), with minimal use of long-lived keys and regular key rotation. Local environment files should contain only non-critical configuration wherever possible.
5. Monitor and respond to suspicious activity. Organizations should log and correlate WebSocket connections and monitor for anomalous terminal or shell usage in cloud and container environments. If compromise is suspected, perform log analysis, revoke potentially exposed keys and tokens, and conduct a focused forensic review of the affected systems.
The exploitation of CVE-2026-39987 in Marimo illustrates that the gap between disclosure of a critical vulnerability and active attacks can be less than ten hours. To reduce risk, organizations need to accelerate vulnerability management, automate patch deployment wherever feasible, and regularly review which services are exposed to the internet. The fewer opportunities attackers have to obtain shell access and harvest secrets from a single compromised component, the lower the likelihood of a security incident escalating into a business-critical breach.
