LLM Agent Spotted Driving Post-Exploitation After Marimo Notebook Compromise

An unattributed actor exploited an internet-facing Marimo notebook and then did something unusual: they let a large language model drive the rest of the operation.

The initial access vector was CVE-2026-39987, a recently disclosed flaw in the Marimo reactive Python notebook platform. From there, the attacker pivoted to two sets of cloud credentials lifted from the compromised host and used an LLM agent to carry out post-exploitation tasks.

No vendor has publicly tied this activity to a tracked cluster. Treat attribution as open.

What makes this notable

Agent-driven intrusions have been a theoretical worry in CTI circles for a couple of years. The capability has been demonstrated in red-team labs and in a handful of vendor write-ups on prompt-injected supply-chain attacks. Operational use against a real victim, with the agent handling reconnaissance and credential triage rather than a human operator at a keyboard, is still rare enough to warrant attention.

The TTP overlap is what's interesting. The exploitation pattern — public-facing notebook, credential extraction, cloud pivot — is consistent with the opportunistic crypto-and-credential crews that have hammered Jupyter and Zeppelin instances for years. What's bolted on top is new.

Capability is not intent. An LLM that can read shell output and pick the next command is useful for both a smash-and-grab cryptominer operator and a more patient intelligence collector. Without telemetry on what the agent actually did after credential extraction, the goal here is unclear.

The Marimo bug

Marimo is a reactive Python notebook gaining traction as a Jupyter alternative. CVE-2026-39987 affects deployments reachable from the public internet — a configuration the project documentation explicitly warns against, but one that ends up shipped anyway. Operators running Marimo should pin to a patched release and put the notebook behind authentication and a network boundary. Treat any notebook server as a code-execution surface, because that is exactly what it is.

Detection notes

A few things worth hunting for:

• Outbound traffic from notebook hosts to LLM API endpoints (OpenAI, Anthropic, Azure OpenAI, Bedrock) that the host has no business talking to.
• Cloud credential use from IPs that do not match the legitimate workload's egress.
• Process trees where a Python notebook kernel spawns shell utilities used for credential harvesting (env, reads of ~/.aws/credentials, IMDS curls).
• Unusual API call cadence in CloudTrail — agentic activity tends to produce bursty, well-formed sequences rather than human-paced exploration.

Medium confidence the same access pattern will show up against other exposed notebook platforms shortly. The bar to bolt an agent onto a credential-theft script is low, and the operational benefits — for the attacker — are obvious.