Human Operator Exploits Marimo RCE and Reaches SSH Bastion in Eight Seconds

A human attacker exploited a critical authentication flaw in the Marimo Python notebook platform, extracted cloud credentials, retrieved a private SSH key, and accessed a bastion host within eight seconds.

Sysdig observed more than 850 interactive commands during an approximately nine-hour intrusion. Rather than deploying a known exploitation framework or an AI agent, the operator built and debugged custom Python scripts inside the compromised environment.

The initial access flaw, CVE-2026-39987, affects CoreWeave Marimo versions earlier than 0.23.0. It is already in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog, confirming exploitation beyond a theoretical proof of concept.

An Unauthenticated WebSocket Opened a Full Shell

Marimo is a reactive Python notebook application. In vulnerable releases, its /terminal/ws WebSocket endpoint can provide an unauthenticated remote user with a complete pseudo-terminal shell.

The underlying problem is missing authentication, classified as CWE-306. The endpoint verifies Marimo’s operating mode and whether the platform supports the requested terminal functionality, but it omits the authentication control applied to other WebSocket routes, including /ws.

Consequently, an Internet-facing instance can allow an attacker to run arbitrary operating-system commands without credentials or user interaction.

The observed operator connected to /terminal/ws from 172.236.12[.]17. Activity continued from 12:52 p.m. until 9:50 p.m., although the calendar date of the intrusion has not been disclosed.

NVD assigns the vulnerability a CVSS v3.1 score of 9.8 with the vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

That assessment describes a network-reachable vulnerability with low attack complexity, no required privileges, no user interaction, and potentially severe effects on confidentiality, integrity, and availability. A separate report gives the flaw a score of 9.3, but NVD’s affected-version definition is more specific: CoreWeave Marimo releases before 0.23.0.

Marimo 0.23.0 contains the fix.

From Notebook Access to the Bastion in Seconds

The attacker did not immediately execute a polished payload. During the intrusion, the operator repeatedly wrote, tested, and corrected Python code, eventually reducing the workflow to a single backgrounded python3 command.

That command automated a five-stage pivot:

1. Read credentials available within the compromised Marimo environment.
2. Use the harvested AWS credentials to query AWS Secrets Manager.
3. Retrieve a stored private SSH key.
4. Save the key to the local filesystem.
5. Authenticate to an SSH bastion host.

The decisive sequence lasted eight seconds. At 18:57:22, the attacker established a new WebSocket connection. At 18:57:26, a query returned the application’s stored AWS key. SSH authentication against the bastion followed at 18:57:30.

This timing matters operationally. Defenders relying on manual review or slow batch analysis would have almost no opportunity to interrupt the transition after the first visible WebSocket event. Prevention, credential isolation, and automated containment are therefore more dependable than expecting an analyst to react during the pivot.

The operator also experimented with an asyncssh-style listener configuration involving an attacker-controlled virtual private server. No recognizable public offensive toolkit was identified in the command history.

Fast Automation Without an AI Agent

The intrusion resembles agentic activity because of its speed, but the evidence points to a human directing custom automation.

More than 850 interactive commands, along with visible script development and debugging, indicate an operator actively refining the attack. Once the necessary steps worked, the attacker combined them into a compact Python process capable of completing the credential-to-SSH chain at machine speed.

Sysdig had also observed automated or agentic operators targeting the same vulnerability. Those operators encountered a defensive trap that stopped or disrupted their workflow; the human attacker avoided it.

That contrast exposes a limitation in controls designed around predictable automation. AI agents and standardized tools may repeat recognizable sequences, trust deceptive responses, or fail when environmental assumptions change. A skilled human can inspect the system, recognize abnormal behavior, and alter the execution path.

This does not make human attackers inherently faster than autonomous systems. It shows that a human can prepare and launch automation after understanding the target, combining adaptive judgment with near-instant execution.

CISA Had Already Classified the Flaw as Exploited

CISA added CVE-2026-39987 to its Known Exploited Vulnerabilities catalog on 2026-04-23. The remediation deadline for covered US federal agencies was 2026-05-07.

The required action is to apply vendor mitigations, follow applicable BOD 22-01 guidance for cloud services, or discontinue using the product if mitigations are unavailable.

Its KEV status means exposed vulnerable installations should not be treated as carrying merely potential risk. Exploitation has been documented, and the newly reported incident demonstrates a path from notebook compromise to sensitive cloud secrets and internal SSH infrastructure.

No other recent Marimo vulnerability in the KEV catalog is identified in the available information. The immediate priority is therefore CVE-2026-39987 and any credentials exposed through vulnerable notebook instances.

What Marimo Operators Should Investigate

Administrators should upgrade every affected Marimo deployment to version 0.23.0 or later. Access to /terminal/ws should also be restricted at the network or reverse-proxy layer, particularly where notebook systems do not need to be publicly reachable.

Patching alone is insufficient if exploitation may already have occurred. Incident responders should assume that credentials accessible to the Marimo process could have been collected.

Recommended actions include:

• Rotate AWS credentials stored on or exposed to the affected instance.
• Review AWS Secrets Manager access for unexpected retrievals from notebook workloads.
• Revoke and replace SSH private keys that the compromised environment could access.
• Search for private keys unexpectedly written to local storage.
• Examine bastion logs for SSH access immediately following Marimo WebSocket sessions.
• Investigate connections involving 172.236.12[.]17.
• Look for backgrounded Python processes and unfamiliar asyncssh-style listeners.
• Correlate /terminal/ws connections with cloud API calls, secret retrieval, filesystem writes, and SSH authentication.

Teams should also determine whether notebook execution roles have permission to retrieve production SSH keys. Removing that access can prevent a notebook compromise from becoming an infrastructure-wide credential pivot.

Separate Campaigns Target Redis and Dahua Cameras

The reporting also described two separate operations that were not attributed to the Marimo attacker.

One cryptomining campaign compromised 3,562 Redis servers after scanning for services exposed on TCP port 6379. The operation used the Redis SLAVEOF command to transfer attacker-controlled content and install the XMRig miner.

Victims ranged from Redis 2.8.17 to 7.2.0 and included both obsolete and current Linux environments. The common exposure appears to have been missing authentication rather than a vulnerability exclusive to one Redis release.

Defenders should remove Redis from direct Internet exposure, require authentication, inspect replication settings, and search for unexpected SLAVEOF activity, append-only-file modifications, SSH keys, and XMRig processes.

A further campaign, Operation CameraSwarm, compromised more than 14,000 Dahua IP cameras using brute-force attacks, peer-to-peer relaying, and the authentication-bypass flaws CVE-2021-33044 and CVE-2021-33045.

Both Dahua vulnerabilities carry CVSS 9.8 ratings and have been in CISA’s KEV catalog since 2024-08-21. The federal remediation deadline was 2024-09-11. Organizations must apply Dahua’s mitigations or discontinue affected devices where mitigation is unavailable.