Blog Published: Jun 6, 2026

Sysdig marimo: When an LLM Agent Drives Post-Exploitation After RCE

Sysdig observed a May 10 intrusion where an attacker used CVE-2026-39987 to reach an internet-facing marimo notebook (marimo is a Jupyter-like interactive Python notebook that runs in the browser), then let an LLM agent drive post-exploitation: credential harvesting, AWS Secrets Manager access, SSH through a bastion, and an internal PostgreSQL dump. The lesson is not only to patch marimo. AI and data-science runtimes need early authentication, narrow credentials, egress limits, segmentation, and telemetry that follows goals rather than fixed command sequences.

Remote Code ExecutionCredential TheftRuntime IsolationCredential GovernanceAgentic AI
6 applicable AIDEFEND defenses
Source: AI agent at the wheel: How an attacker used LLMs to move from a CVE to an internal database in 4 pivots 
Author: Michael Clark (Sysdig Threat Research Team)
Original article: May 26, 2026

Threat Analysis

  • Initial access was a notebook shell. The attacker connected to /terminal/ws on a vulnerable, internet-reachable marimo instance and gained command execution through CVE-2026-39987.
  • The first pivot was credential harvest. The session read environment files, .env paths, process environments, and ~/.aws/credentials, then used harvested AWS keys to call STS and Secrets Manager.
  • The second pivot turned a secret into SSH reach. The attacker retrieved an SSH private key, used Cloudflare Workers as an egress pool, and opened eight short SSH sessions to a downstream bastion.
  • The agent signature appears in the command stream. Sysdig cites a leaked planning comment, delimiter-heavy shell blocks, bounded output captures, a single psql heredoc, and values lifted from prior tool output.
  • The payload was an internal database dump. The bastion phase enumerated PostgreSQL tables, guessed high-value AI-workflow tables, and exfiltrated schema and contents in under two minutes.

Applicable AIDEFEND Defenses (6)

AID-H-004.002
Service & API Authentication
Very High
The first break point is the terminal WebSocket and any AI notebook control surface that can reach a shell, secrets, or internal services. Service and API authentication should run before terminal creation, notebook execution, model-serving APIs, data stores, and MLOps actions are reachable, so an unauthenticated request cannot become a host shell.
AID-I-001.004
Sandbox Network Egress Restrictions
Very High
The chain depended on outbound reach from the compromised runtime to cloud APIs, Cloudflare Workers, SSH, and the internal database path. Default-deny egress for notebook and code-execution sandboxes would sharply reduce callback traffic, credential replay, and lateral movement after RCE.
AID-I-002.001
Internal AI Network Segmentation
High
The intrusion became severe because a compromised data-science runtime could help reach AWS Secrets Manager, a bastion, and an internal PostgreSQL database. Network segmentation and microsegmentation should prevent public-facing AI notebooks from directly reaching high-value internal data stores or administrative jump paths.
AID-M-005.002
Configuration Baseline Definition & Posture SLOs (Service Level Objectives)
High
Marimo exposure, terminal enablement, credential placement, and patch level are deployment posture decisions. Baselines should block internet-facing notebook shells without approved authentication, require patched marimo versions, define which workloads may hold cloud credentials, and gate exceptions with owners and expiry.
AID-D-005.002
Security Monitoring & Alerting for AI
High
Sysdig's evidence is rich telemetry: terminal WebSocket access, credential-file enumeration, STS and Secrets Manager calls, Cloudflare Workers fan-out, short SSH sessions, and PostgreSQL dumps. AI-aware monitoring should alert on these goals even when each command sequence is composed differently by an agent.
AID-E-001.001
Foundational Credential Management
Medium
The attacker moved by reusing AWS keys, SSH material, and database passwords found after initial access. Once a marimo runtime has been public or compromised, teams need immediate rotation for cloud credentials, API keys, database passwords, SSH keys, and any long-lived service credentials reachable from the process.

What Defenders Should Do Now

  • Upgrade marimo to 0.23.0 or later. If upgrade is delayed, restrict access to /terminal/ws, disable the terminal feature, and place notebook services behind strong authentication and private network paths.
  • Inventory internet-facing notebooks, AI sandboxes, data-science UIs, and MCP or agent development surfaces. Record whether each one can execute shell commands, read environment variables, or reach cloud APIs.
  • Rotate credentials on any marimo host that was exposed. Include AWS keys, API keys, database passwords, SSH keys, local secrets, and service credentials mounted into the runtime.
  • Move notebook and code-execution workloads into sandboxes with default-deny egress. Add only reviewed outbound destinations, and keep cloud APIs, bastions, and internal databases off the default route.
  • Segment internal databases and bastions away from AI experimentation hosts. A public notebook should not be able to discover, SSH into, or query production data stores without an explicit, logged path.
  • Add detections for credential-file reads, secretsmanager:GetSecretValue bursts, per-request egress pools, unusual SSH fan-out, delimiter-heavy shell probes, and database dumps after notebook activity.

Conclusion

Sysdig's marimo case matters because the LLM did not invent a new exploit. It made post-exploitation cheaper, faster, and more adaptive after a conventional RCE. AIDEFEND  maps the defense to early service authentication, sandbox egress limits, internal segmentation, posture baselines, AI-aware monitoring, and credential rotation. The durable goal is to make AI notebook compromise a contained incident, not a shortcut to cloud secrets and internal databases that opens the door to far greater damage.