Hackers Exploit Marimo RCE to Steal AWS Credentials and Reach Bastion Host in 8 Seconds

Threat actors have been observed exploiting a critical remote code execution vulnerability in the Marimo notebook platform to steal AWS credentials and authenticate to an SSH bastion host within eight seconds.

The attack, documented by the Sysdig Threat Research Team, abused CVE-2026-39987, a pre-authentication remote code execution flaw affecting Marimo versions up to and including 0.20.4. The vulnerability was fixed in Marimo version 0.23.0.

Marimo is an open-source reactive Python notebook platform commonly used by developers, data scientists, and machine-learning teams.

Because notebook servers can run alongside cloud workloads, datasets, API tokens, and development tools, a compromise can provide attackers with valuable access to sensitive environments.

The vulnerable component was Marimo’s terminal WebSocket endpoint. Researchers said the endpoint did not correctly enforce authentication checks.

An attacker could open a WebSocket connection and receive an interactive shell as the user running the Marimo process, without valid credentials.

Marimo RCE Steals AWS Credentials in 8 Seconds

In the observed intrusion, the attacker used custom-built tooling rather than an AI or large language model agent. Despite the manual approach, the operator moved at machine speed through the compromised environment.

Sysdig found that only eight seconds passed between opening a new WebSocket session and successfully authenticating via SSH to a downstream bastion host.

After gaining access to the Marimo server, the attacker searched for cloud credentials exposed through the host environment and the application’s Redis backend. The attacker then used the stolen AWS credentials to query AWS Secrets Manager.

The Secrets Manager request returned an SSH private key. The attacker immediately used that key to authenticate to an internet-accessible SSH bastion host, also known as a jump server.

Bastion hosts are often used as controlled entry points for administrators accessing systems inside private cloud networks. Their compromise can give attackers a direct route to internal resources.

The rapid credential-to-bastion pivot shows why cloud permissions must be tightly scoped. A notebook instance should not have broad permission to read secrets unrelated to its normal workload.

In this case, credentials available on the compromised Marimo host could access an SSH key that enabled lateral movement into another part of the environment.

The incident also highlights the danger of exposed developer and machine-learning infrastructure. Teams often deploy notebook servers quickly for experimentation.

However, they may retain access to AWS services, source code, datasets, model-provider credentials, and internal systems. A single unauthenticated service can become an entry point for a much wider cloud breach.

Organizations using Marimo should upgrade to version 0.23.0 or later immediately. Security teams should also identify public-facing Marimo deployments, disable or protect unnecessary terminal endpoints, and ensure WebSocket services require authentication.

AWS administrators should review IAM permissions attached to notebook workloads, especially access to AWS Secrets Manager. Credentials should follow least-privilege rules and must not be able to retrieve unrelated SSH keys, production secrets, or high-value access tokens.

Teams should rotate AWS credentials, SSH keys, API tokens, and other secrets that may have been exposed on vulnerable instances.

Monitoring should also focus on unusual Secrets Manager requests, unexpected credential use, new SSH authentications to bastion hosts, and rapid sequences of cloud API activity following application access.

The attack demonstrates that a human-operated intrusion can execute a full exploit-to-lateral-movement chain in seconds when cloud credentials and privileged secrets are left within reach.

Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.