Security researchers have identified active exploitation of a critical vulnerability in Marimo, an open-source reactive Python notebook environment widely used by data scientists, machine learning engineers, and developers building data-driven applications.
The vulnerability, tracked as CVE-2026-39987, enables unauthenticated remote code execution (RCE) in Marimo versions 0.20.4 and earlier. With a severity score of 9.3 out of 10, the flaw represents a critical security risk for environments where Marimo instances are exposed to external networks.
According to research conducted by Sysdig, attackers began exploiting the vulnerability within 10 hours of its public disclosure, highlighting the increasing speed at which threat actors weaponize newly disclosed vulnerabilities.
Understanding the Marimo WebSocket RCE Vulnerability
The vulnerability stems from improper authentication controls on the WebSocket endpoint:
/terminal/ws
This endpoint exposes an interactive terminal session without validating user authentication. As a result, any remote attacker can connect directly to the terminal and execute arbitrary commands.
Because the terminal runs under the same permissions as the Marimo process, attackers effectively gain full shell access to the host environment where the application is running.
This flaw particularly impacts deployments where:
- Marimo is running in editable notebook mode
- The application is exposed on a shared or public network
- The service is started with the parameter:
--host 0.0.0.0
This configuration allows the application to accept connections from any external host, dramatically increasing the attack surface.
Rapid Exploitation Following Public Disclosure
Marimo developers disclosed the vulnerability on April 8, alongside a security advisory describing the issue. Within hours, security researchers observed scanning activity targeting exposed instances.
Telemetry collected by Sysdig identified 125 unique IP addresses conducting reconnaissance within the first 12 hours after the vulnerability details were published.
The first exploitation attempt occurred less than 10 hours after disclosure, demonstrating the speed at which attackers monitor vulnerability advisories and develop working exploits.
Attack Methodology Observed in the Wild
Initial exploitation attempts followed a clear sequence designed to validate the vulnerability and harvest sensitive credentials.
Step 1: Vulnerability Validation
Attackers first connected to the vulnerable WebSocket endpoint:
/terminal/ws
They executed a short scripted command sequence to confirm successful remote command execution before disconnecting within seconds.
Step 2: Manual Environment Reconnaissance
After verifying the vulnerability, attackers returned and initiated a manual reconnaissance session using common Linux commands such as:
pwd
whoami
ls
These commands allowed the attacker to identify the current working directory, system user privileges, and accessible files within the environment.
Additional commands were issued to explore directories and identify locations containing sensitive system data or credentials.
Credential Harvesting and Secret Extraction
Once the attacker understood the environment, they focused on extracting sensitive configuration files and credentials.
The primary target was the .env configuration file, which typically contains environment variables used by applications. These variables often include sensitive secrets such as:
- Cloud provider credentials
- API keys
- Database connection strings
- Application authentication tokens
For example, environment variables discovered in compromised systems included AWS credentials, application configuration values, and host environment settings.
Attackers also attempted to locate and access directories commonly associated with SSH authentication, seeking private keys that could enable further lateral movement.
According to the Sysdig analysis, the entire credential harvesting phase took less than three minutes, indicating a highly targeted operation.
Indicators of a Targeted Intrusion
Interestingly, researchers observed that the attacker did not deploy typical post-exploitation tools such as:
- Cryptomining malware
- Persistence mechanisms
- Backdoors or web shells
Instead, the activity suggests a stealth-oriented operator focused on rapid credential theft, possibly for use in follow-up attacks targeting cloud infrastructure or development environments.
Approximately one hour later, the attacker returned for a second session using the same exploitation technique, reinforcing the hypothesis that the attack was conducted manually rather than through fully automated scripts.
Security Patch and Immediate Remediation
The Marimo development team addressed the vulnerability in version 0.23.0, which introduces proper authentication checks for the exposed terminal endpoint.
Organizations running vulnerable versions should upgrade immediately to eliminate the risk of unauthorized access.
Recommended remediation steps include:
1. Update Marimo Immediately
Upgrade to the patched version:
Marimo 0.23.0
2. Restrict Network Exposure
Avoid exposing development tools directly to the public internet. Where possible, restrict access through:
- Firewall rules
- VPN gateways
- Internal-only network segmentation
3. Monitor WebSocket Activity
Security teams should review logs for suspicious connections to:
/terminal/ws
Unrecognized WebSocket connections may indicate attempted exploitation.
4. Rotate Potentially Compromised Credentials
If a vulnerable Marimo instance was exposed to the internet, organizations should assume credentials may have been compromised and rotate:
- Cloud provider keys
- API tokens
- Database credentials
- SSH keys
5. Temporary Mitigation
If patching cannot be performed immediately, administrators should disable or block access to the /terminal/ws endpoint entirely until an update can be applied.
Broader Security Implications for Developer Platforms
This incident highlights a growing cybersecurity challenge: developer tools and notebook environments increasingly operate in cloud-connected infrastructure but often lack production-grade security controls.
Platforms used for data science, machine learning, and development workflows frequently contain:
- Sensitive cloud credentials
- Internal APIs
- Infrastructure automation scripts
As a result, vulnerabilities in these tools can become high-value entry points for attackers seeking access to broader cloud environments.
Organizations deploying developer platforms in shared or internet-facing environments must therefore apply the same security standards used for production applications, including strong authentication, network isolation, and continuous monitoring.