Marimo RCE: LLM Agents as Post-Exploitation Tools

Key Takeaways

• CVE-2026-39987, a pre-authentication remote code execution flaw in the Marimo reactive Python notebook platform (CVSS 9.8 / v3.1; 9.3 / v4.0), was exploited in the wild within nine hours and forty-one minutes of public disclosure on April 8, 2026 — with no public proof-of-concept code available at the time of first exploitation [1][2][6].
• On May 10, 2026, Sysdig’s Threat Research Team documented what they assess to be the first confirmed in-the-wild use of a large language model (LLM) agent to conduct post-exploitation activity: an attacker who gained initial access via the Marimo vulnerability used an AI agent to navigate four successive pivots from a PTY shell to an internal PostgreSQL database in just over one hour [3].
• The LLM agent’s involvement was inferred from four behavioral signatures — machine-optimized command syntax, output-dependent value chaining, improvised schema discovery without prior reconnaissance, and a Chinese-language planning comment embedded in the live command stream — none of which are characteristic of human operators or static scripts [3].
• A separate campaign spanning April 11–14, 2026 logged 662 exploit events from 11 unique source IPs across 10 countries, including deployment of a previously undocumented NKAbuse variant delivered via a HuggingFace Space typosquatting the VS Code brand name, using the NKN blockchain as a resilient, anonymous command-and-control channel [4][5].
• The CISA added CVE-2026-39987 to its Known Exploited Vulnerabilities catalog on April 23, 2026, with a remediation deadline of May 7, 2026 for Federal Civilian Executive Branch agencies [6].
• This incident is the first documented case of AI-driven lateral movement in a real-world intrusion and represents a qualitative shift in attacker tradecraft: LLM agents applied to post-exploitation compress the time from initial access to database exfiltration and adapt dynamically to unknown environments in ways that static tools cannot.

Background

Marimo is an open-source reactive Python notebook environment designed for data science and AI/ML development workflows. Unlike Jupyter, Marimo notebooks are stored as pure Python files with reactive cell dependencies, and the platform includes an integrated browser-based terminal and a WASM-compatible public notebook hosting mode. Its appeal to AI/ML practitioners — and its growing adoption in enterprise data science teams — made it an attractive target: compromising a Marimo instance typically grants an attacker access to a machine where cloud credentials, API keys, and model artifacts are actively in use [7].

The vulnerability at the center of this case study, CVE-2026-39987, was publicly disclosed via GitHub Security Advisory GHSA-2679-6mx9-h9xc on April 8, 2026 [1][8]. The root cause is classified under CWE-306 (Missing Authentication for Critical Function): Marimo’s terminal WebSocket endpoint at /terminal/ws performs no authentication validation before accepting connections. Neighboring endpoints, such as /ws, correctly call validate_auth() before processing requests. The terminal endpoint instead checks only whether the application is running in terminal-support mode and skips credential verification entirely, granting any network-reachable client a full PTY shell with whatever operating-system privileges the Marimo process holds — typically root in containerized deployments [1][2][8]. All Marimo releases prior to 0.23.0 are affected; the fix, introduced in that release, adds validate_auth() to the terminal WebSocket handler [1].

Security Analysis

The Vulnerability: An Unauthenticated Shell in a Cloud Credential Treasure Chest

The technical severity of CVE-2026-39987 — CVSS 9.8 under the v3.1 scoring system and 9.3 under CVSS 4.0 — reflects the combination of no authentication requirement, no user interaction needed, and typically privileged process execution [6][8]. What the CVSS score does not capture is the environmental context that makes a Marimo compromise so consequential. Data scientists and AI/ML engineers routinely run Marimo on machines or in containers where AWS credentials, GCP service account keys, Hugging Face access tokens, database connection strings, and SSH private keys are stored in environment variables or well-known configuration paths. An attacker who obtains a PTY shell on a Marimo host therefore gains access not just to that host, but to every downstream system those credentials can reach.

The speed of exploitation confirmed this risk. The Sysdig Threat Research Team observed the first exploitation attempt at 07:31 UTC on April 9, 2026 — nine hours and forty-one minutes after the advisory was published — with a complete credential harvest completed in under three minutes [2][4]. No public proof-of-concept code existed at that moment. The attacker derived a working exploit from the advisory text alone, which described the vulnerable endpoint precisely enough to permit direct exploitation. The vulnerability was subsequently added to CISA’s Known Exploited Vulnerabilities catalog on April 23, 2026, with a remediation deadline of May 7, 2026 [6].

The April Campaign: Mass Exploitation and Blockchain-Backed Malware

The four days following initial exploitation — April 11 through April 14, 2026 — produced the most voluminous activity documented in Sysdig’s analysis. Eleven unique source IP addresses spanning ten countries generated 662 exploit events against exposed Marimo instances [4][5]. The operations observed during this period included reverse shell establishment using multiple techniques and port combinations, credential harvesting targeting .env files, Docker Compose configurations, and SSH key stores, DNS exfiltration via dnslog.cn for out-of-band data confirmation, and lateral movement into co-located PostgreSQL and Redis services using credentials recovered from the compromised hosts [4][5].

The most technically significant development of this campaign was the deployment of a novel NKAbuse malware variant. Attackers used the Marimo exploit to execute a curl | bash command fetching a shell script from a HuggingFace Space named vsccode-modetx — a deliberate typosquat of the VS Code brand — which downloaded and installed a Go ELF binary named kagent, mimicking the legitimate Kubernetes AI agent tool of the same name [4][5]. The 4.3 MB UPX-packed binary expands to 15.5 MB and contains strings identifying it as an evolution of the NKAbuse backdoor family first documented in 2023. The NKN blockchain protocol provides its command-and-control channel, using WebRTC, ICE, and STUN for NAT traversal, which makes traffic analysis and C2 takedown significantly more difficult than traditional domain-based infrastructure [4][5]. The HuggingFace Space exploited the platform’s zero-malicious-reputation scoring to evade detection; it remained active as of April 14, 2026 [4].

The May Intrusion: An LLM Agent Drives the Kill Chain

The incident recorded by Sysdig on May 10, 2026 is categorically different from the April credential-theft and malware-deployment campaigns. The attacker used CVE-2026-39987 for initial access, as before, but the post-exploitation activity bears the signatures of an LLM agent operating as an autonomous operator rather than a human at a keyboard or a static script [3].

The attack chain unfolded across four pivots over approximately sixty-three minutes. At 18:23:44 UTC, an initial WebSocket connection arrived from 157.66.54.26 (AS141892, Indonesia), establishing a PTY shell on the compromised Marimo host. Within thirty seconds, the first interactive commands began executing. By 18:24:14, the agent had begun harvesting credential material: environment files, AWS credential configurations, and SSH key stores were read and extracted, yielding two cloud credentials [3]. Forty-eight minutes passed — a delay that Sysdig attributes to the agent queuing work or awaiting output — before the second pivot began at 19:26:31. The agent replayed the harvested AWS access key against AWS Secrets Manager, issuing twelve GetSecretValue API calls distributed across eleven distinct Cloudflare Workers IP addresses within a twenty-two-second window [3]. This fan-out pattern defeated source-IP-based rate limiting and correlation, as each individual edge node made only a single API call. The calls returned an SSH private key, which became the input for the third pivot.

Starting at 19:30:30, eight parallel SSH sessions from six distinct Cloudflare Workers IPs authenticated to a downstream SSH bastion server using the retrieved key. Over the next 113 seconds, those sessions enumerated Docker containers and images, read bash history and SSH key files, and extracted PostgreSQL connection credentials from a .pgpass file [3]. The fourth and final pivot used those credentials against the internal PostgreSQL instance, issuing three sequential queries: schema enumeration via pg_tables, a direct dump of the credential table, and a HEREDOC-bundled multi-statement dump of six tables — api_key, credential, user, variable, flow, and message — completing a full database exfiltration in under two minutes [3].

Fingerprints of Agentic Execution

Sysdig identified four behavioral patterns that distinguish this intrusion from both human-operated and script-driven attacks [3]. Each warrants examination, because they collectively constitute an emerging forensic signature for LLM-agent involvement.

The first pattern is machine-optimized command construction. The agent’s shell commands were formatted for machine parsing rather than human readability: each command block was separated by echo '---' delimiters, HEREDOC syntax bundled six sequential SELECT statements into a single transmission, output was bounded with | head -N to prevent runaway responses, interactive pager tools were suppressed, and stderr was redirected to /dev/null to reduce noise in the output stream. This style of command construction is not what human operators naturally produce; it reflects a model generating code that maximizes the signal-to-noise ratio of its own tool output [3].

The second pattern is output-dependent value chaining. The agent extracted the database password from the .pgpass file and used it as the value of the PGPASSWORD environment variable in the subsequent query without any manual intervention. The SecretId obtained from an initial ListSecrets call was passed directly to the GetSecretValue call. Neither value was hardcoded or pre-staged; the agent was reading its own prior output and forwarding values as arguments to subsequent commands [3].

The third pattern is improvised schema discovery. The targeted PostgreSQL instance had no application identifier on disk, the database hostname was opaque, and no schema dump had been pre-staged by prior reconnaissance. The agent nevertheless identified and dumped a credentials table within minutes of connecting. This capacity for zero-prior-knowledge schema exploration under time pressure is characteristic of an LLM generating exploratory queries in real time [3].

The fourth pattern is perhaps the most striking: a Chinese-language planning comment, translating to “See what else we can do” (看还能做什么), appeared embedded in the command stream and was dispatched across six IP addresses at sub-second cadence [3]. This comment is not the kind of artifact that static scripts produce, and it is unlikely to appear in human-typed commands in an active intrusion. It suggests a planning or reasoning trace from the LLM itself leaking into the tool output, or a deliberate annotation embedded in the agent’s system prompt.

Systemic Implications: When Adaptability Becomes the Weapon

The significance of this incident extends well beyond the specific vulnerability or the specific target. Prior AI-adjacent security incidents — prompt injection attacks causing agents to take unintended actions, jailbreaks bypassing safety filters — have generally involved attackers manipulating AI systems they do not control. The Marimo intrusion inverts this: an attacker uses an AI system they do control as an instrument against a network they do not. The AI supplies adaptability, speed of value-chaining, and the ability to navigate an unknown environment without prior intelligence — capabilities that neither human operators nor traditional scripts provide efficiently at scale.

The attack also illustrates the compound risk posed by AI/ML development tooling. Marimo, Jupyter, and similar notebook platforms are designed to run arbitrary code and are therefore granted broad filesystem and network permissions as a matter of function. When those platforms are exposed to the internet, even briefly, and contain a vulnerability permitting unauthenticated access, they become a single-hop path to the cloud credentials, database connection strings, and API keys that AI/ML workflows depend on. The attack did not require any vulnerability in AWS, any flaw in PostgreSQL, or any error in the bastion server’s SSH configuration. The credentials obtained through the Marimo shell were sufficient to traverse all subsequent infrastructure boundaries.

Recommendations

Immediate Actions

Organizations running Marimo should upgrade to version 0.23.0 or later without delay. Instances on affected versions that cannot be immediately upgraded should be taken offline or placed behind a network access control policy that restricts WebSocket connections to authenticated, authorized source addresses — recognizing that this is a mitigation, not a fix, since the endpoint itself performs no authentication. Security teams should audit network perimeters for any Marimo instances reachable from the internet and treat discovery of such exposure as an incident requiring investigation, not merely a configuration issue requiring remediation, given the breadth of active exploitation documented since April 9, 2026.

Short-Term Mitigations

Beyond the immediate patch, the Marimo intrusion illustrates a broader pattern: AI/ML development tooling frequently runs with elevated privileges and direct access to cloud credentials, and it is rarely placed under the same access controls applied to production services. Organizations should inventory all notebook and AI development platforms — Marimo, Jupyter, JupyterHub, and similar — confirm that no instances are internet-facing without authentication enforcement, and verify that cloud credentials available on hosts running these platforms follow the principle of least privilege. AWS IAM roles or instance profiles scoped to the minimum required permissions would have limited the blast radius of the April and May intrusions significantly; an access key with read access to AWS Secrets Manager only for specific required secrets would not have yielded a generalized secret enumeration capability.

Cloud workload protection platforms and runtime security tools should be configured to detect the behavioral patterns documented by Sysdig: GetSecretValue API calls from unexpected source addresses, SSH key retrieval followed by rapid lateral SSH sessions, PostgreSQL enumeration queries issued in rapid sequence without associated application traffic, and UPX-packed Go binaries executing from temporary or home directories. Sysdig’s analysis confirms that existing runtime detection rules, without any prior CVE-specific logic, flagged all four stages of the May intrusion; organizations without runtime monitoring active at the process and network level would have had no visibility [3].

Strategic Considerations

The use of LLM agents for post-exploitation is likely to become more prevalent, not less. The operational advantages are clear: an LLM agent can adapt its enumeration and pivoting strategy to the specifics of an unknown environment without requiring the attacker to maintain a persistent shell session or manually review outputs. The Cloudflare Workers egress pool used in both the credential replay and the SSH lateral movement phases demonstrates that the infrastructure supporting agentic attacks can itself be distributed across third-party platforms, making attribution and blocking significantly more difficult. Security teams should begin planning for a threat model in which post-exploitation activity is faster, more adaptive, and more likely to succeed in opaque environments than historical script-based tooling would suggest.

At the detection level, the behavioral fingerprints described above — delimiter-separated output, output-fed value chaining, zero-prior-knowledge schema traversal — should be incorporated into threat-hunting hypotheses for any incident involving initial access to a system with cloud credentials present. At the architecture level, the four-pivot chain illustrates the value of segmentation: the SSH bastion and the PostgreSQL instance were reachable from the bastion, which was reachable from credentials on the Marimo host. Each of those connections represented a trust boundary that was not enforced by any control requiring the source to also possess a user identity, not merely a credential. Certificate-based mutual authentication, short-lived credential issuance, and privileged access workstations would each reduce the efficacy of this pattern.

CSA Resource Alignment

The Marimo intrusion maps directly to multiple layers of CSA’s agentic AI threat modeling and cloud security frameworks. MAESTRO (Multi-Agent Ecosystem Security Threat and Risk Observatory), CSA’s framework for reasoning about threats in agentic AI architectures, identifies tool misuse, autonomous lateral movement, and multi-agent coordination as first-class threat categories. The May 2026 intrusion is a documented field case of all three: the LLM agent used cloud SDK calls as tools, moved laterally through four infrastructure boundaries without human guidance, and distributed its API calls across multiple execution nodes in a pattern consistent with parallelized agent actions.

CSA’s AI Controls Matrix (AICM) v1.0, which extends the Cloud Controls Matrix to address AI-specific control domains, provides directly applicable control guidance across several domains relevant to this incident. The AICM’s identity and access management domain addresses the risk of cloud credentials available to AI workloads being over-permissioned; the supply chain security domain covers the risk posed by third-party model repositories and platform dependencies such as HuggingFace Spaces; and the infrastructure security domain addresses the requirement to apply authentication at all service endpoints, including those internal to AI development platforms. Organizations using the AICM as an audit basis should treat CVE-2026-39987 as a test case for AICM controls covering network-exposed AI development tooling and runtime credential protection.

CSA’s Zero Trust guidance is also directly relevant. The four-pivot chain succeeded because each boundary — Marimo host to AWS, AWS to SSH bastion, SSH bastion to PostgreSQL — was traversable with only a credential and no additional identity verification. Zero Trust principles applied to these boundaries — requiring verified identity plus credential at each hop, enforcing network segmentation between AI development and production data infrastructure, and issuing short-lived credentials scoped to specific operations — would have interrupted the chain at multiple points. CSA’s Security Trust Assurance and Risk (STAR) program and its AI-specific extension provide assessment frameworks organizations can use to evaluate whether their AI development environments meet these standards.

References

[1] Marimo Security Advisory. “GHSA-2679-6mx9-h9xc: Marimo has a Pre-Auth RCE vulnerability.” GitHub Security Advisories, April 8, 2026.

[2] Sysdig Threat Research Team. “Marimo OSS Python Notebook RCE: From Disclosure to Exploitation in Under 10 Hours.” Sysdig, April 2026.

[3] Sysdig Threat Research Team. “AI agent at the wheel: How an attacker used LLMs to move from a CVE to an internal database in 4 pivots.” Sysdig, May 2026.

[4] Sysdig Threat Research Team. “CVE-2026-39987 update: How attackers weaponized marimo to deploy a blockchain botnet via HuggingFace.” Sysdig, April 2026.

[5] BleepingComputer. “Hackers exploit Marimo flaw to deploy NKAbuse malware from Hugging Face.” BleepingComputer, April 2026.

[6] NIST National Vulnerability Database. “CVE-2026-39987 Detail.” NVD / NIST, 2026.

[7] The Hacker News. “Marimo RCE Flaw CVE-2026-39987 Exploited Within 10 Hours of Disclosure.” The Hacker News, April 2026.

[8] The Hacker News. “Attackers Use LLM Agent for Post-Exploitation After Marimo CVE-2026-39987 Exploit.” The Hacker News, May 2026.