Marimo RCE Hit by Human at Machine Speed

The distance between a vulnerable notebook and an SSH bastion host is often measured in minutes or hours. In one incident reviewed by Sysdig's Threat Research Team, an operator covered it in eight seconds — using a toolkit they assembled by hand, with no sign of a large language model involved at any point.

The finding, laid out in a technical write-up published on September 11, describes a human attacker reaching a machine-speed pace usually attributed to automated or AI-driven campaigns. Sysdig reported that the operator exploited CVE-2026-39987, a pre-authentication remote code execution flaw in the Marimo notebook platform.

Eight Seconds From Notebook to Bastion

According to Sysdig, the operator moved from the vulnerable Marimo notebook to an SSH bastion host in eight seconds. The write-up states that the operator exploited CVE-2026-39987 and showed no sign of using a large language model at any stage.

The flaw affects Marimo up to and including 0.20.4 and is fixed in 0.23.0. It lives in the terminal WebSocket endpoint, which skipped the authentication check applied to the platform's other WebSocket endpoints. Any client that opened a connection to that endpoint received an interactive shell as the Marimo process user, with no credentials required.

Sysdig said this matters because Marimo notebooks usually run alongside machine learning pipelines, on hosts holding GPU access, large datasets and credentials for AWS, GCP and model providers. In its assessment, a compromised notebook is the door to the victim's cloud account.

Credential Harvesting on Two Surfaces

The operator harvested cloud credentials from two surfaces on the host: the process environment and the application's Redis backend. Those credentials were then replayed against the AWS account.

One of them returned an SSH private key from AWS Secrets Manager. That key was used to authenticate to an internet-reachable bastion host.

The write-up describes the eight seconds as the visible portion of a much longer effort. Sysdig said the operator spent roughly four hours building and debugging the Python toolkit across earlier sessions, storing eight scripts on the host so that a later reconnection could fire the finished chain from a single command.

Across a nine-hour session, the operator logged more than 850 interactive commands and used no recognizable public offensive tooling.

The Trap Built to Catch LLM Agents

Sysdig had planted a directive in the vulnerable container specifically to catch LLM agents. The directive told any model that read a particular file to echo a hidden marker into its output.

Every AI-driven operator profiled against this flaw echoed that marker. This operator inspected the same file twice and never echoed it. The prompt injection trap, which reliably caught AI agents, did not catch a human.

Sysdig described the result as its clearest non-LLM signature to date.

Same Endpoint, Different Typing

Sysdig reported that detection cannot lean on the fingerprints of one attacker type. An LLM-generated command stream and a hand-typed one look completely different, but in this case they ended at the same Secrets Manager call, the same SSH key handoff and the same bastion connection.

In Sysdig's framing, the priority is the shape of the chain rather than the typing.

What Sysdig Recommends

The write-up lists several steps for defenders. These include updating to 0.23.0, putting the terminal endpoint behind authentication or disabling it, scoping Secrets Manager permissions so a notebook's credentials cannot read a bastion key, and rotating anything exposed on a reachable instance.

The recommendations correspond to points in the chain Sysdig observed: an unauthenticated terminal endpoint, credentials readable from the process environment and Redis, and a secret that yielded a key capable of authenticating to a reachable host.

Mixed Data Points on the Record

• Eight seconds — time from the vulnerable Marimo notebook to an SSH bastion host
• Four hours — time Sysdig says the operator spent building and debugging the Python toolkit
• Eight scripts — stored on the host for the later reconnection
• 850+ interactive commands — logged over a nine-hour session
• 0.20.4 — highest affected Marimo version; 0.23.0 is the fix
• May 7, 2026 — federal remediation deadline tied to the CVE's KEV listing

The CVE's Standing on the KEV Catalog

CVE-2026-39987 has been on CISA's Known Exploited Vulnerabilities (KEV) catalog for months, with a federal remediation deadline of May 7, 2026.

The flaw's placement on the catalog predates the incident described in the Sysdig write-up. The catalog entry reflects the vulnerability's known exploitation status, while the write-up describes how one operator used it in a specific intrusion.

Why It Matters

For organizations running Marimo, the immediate question is internal: which version is deployed, and what credentials sit within reach of the notebook process. The chain Sysdig describes could, in principle, be reproduced by anyone willing to invest the same build time — the write-up offers no evidence that the toolkit has been shared or reused elsewhere.

The detection lesson is the harder one to act on. If a prompt injection trap built to catch LLM agents missed this operator, then tooling that keys on AI-generated command patterns may not cover hand-typed activity that reaches the same secrets. Defenders may get more durable coverage by watching the endpoints of the chain itself — the secrets access, the key handoff, the bastion login — rather than the style of the commands leading up to them.

That shift in focus depends on whether those endpoints are instrumented at all. Cloud credential access, Secrets Manager reads and bastion authentications each generate their own telemetry; whether an organization collects and correlates them is a separate question from how the attacker types.

Sysdig's write-up also underscores a scoping problem. Credentials that a notebook can read are credentials an attacker who reaches the notebook can use, and the AWS key in this incident traveled from a notebook-accessible storage location to a host reachable from the internet.