AI-Powered LLM Agent Exploits Marimo RCE and Dumps Internal Database in Under Two Minutes
Researchers have documented the first confirmed intrusion in which a large language model (LLM) agent autonomously executed a complete post-exploitation chain, moving from a single exposed notebook server to a fully exfiltrated internal database in fewer than 120 seconds. The attack, captured on May 10, 2026, by Sysdig’s Threat Research Team (TRT), is not just a technical milestone. It is a direct signal to Canadian IT defenders that AI is no longer only a tool of defense.
The Vulnerability at the Core: CVE-2026-39987
The entry point was CVE-2026-39987, a critical remote code execution flaw in Marimo, an open-source reactive Python notebook platform. The vulnerability lives in the application’s terminal WebSocket endpoint. A single malformed WebSocket request is all an attacker needs to obtain an interactive shell on any unpatched marimo server exposed to the internet.
The flaw has since been added to CISA’s Known Exploited Vulnerabilities catalog, and the federal remediation deadline has already passed. Canadian organizations running Marimo in data science, research, or analytics environments should treat any internet-facing instance as potentially compromised until patched.
How the Attack Unfolded: Four Pivots, One Agent
The attack progressed in four clearly defined stages, each building on output gathered in the previous one.
Pivot 1: Shell Access via WebSocket Exploit
The attacker’s origin IP (157.66.54.26, geolocated to Indonesia via AS141892) connected to the exposed Marimo server and triggered the WebSocket RCE. From that initial shell, the agent began enumerating the host environment immediately, reading credential files, environment variables, and filesystem paths with structured, machine-optimized commands designed for clean programmatic output.
Pivot 2: AWS Credential Harvesting
Environment files and the local AWS credentials store yielded active cloud access keys. The agent used those keys to call AWS Secrets Manager’s ListSecrets API, selecting and retrieving an SSH private key within 20 seconds of obtaining the initial credential. To defeat cloud-side alerting, the agent fanned 12 AWS API calls across 11 distinct Cloudflare Workers IP addresses inside a 22-second window, a distribution technique that directly neutralizes per-source-IP correlation, which is how most cloud-native security tools flag suspicious API activity.
Pivot 3: Lateral Movement to Bastion Host
Armed with the SSH private key, the agent opened eight parallel SSH sessions against a downstream bastion server. Those sessions originated from six separate IP addresses simultaneously. The parallel, distributed approach is not something a human operator or static script would generate organically. It points directly to an automated agent adapting its evasion strategy in real time.
Pivot 4: Internal PostgreSQL Database Exfiltration
From the bastion, the agent reached an internal PostgreSQL database. Without any pre-staged schema knowledge, it enumerated tables and immediately prioritized a credential table. The database password was pulled directly from a .pgpass file the agent had read moments earlier. The full dump was completed in under two minutes from initial shell access.
The Four Markers of LLM Agent Involvement
Sysdig’s TRT identified four technical indicators confirming that an LLM agent, not a human operator or pre-written script, drove this attack.
The first was adaptive reasoning without prior intelligence. The agent targeted a credential table that does not exist in the application schema most closely resembling. It was drawing on generalized knowledge about how credential storage is typically structured, not pre-staged target intelligence.
The second was an embedded planning comment in Chinese, translating roughly to “see what else we can do,” appearing directly in the command stream at sub-second cadence across six IPs. No human typist produces that pattern.
Third, every command was structured for machine consumption: bounded output, structured separators, and discarded error streams so the agent could parse each result cleanly before issuing the next instruction.
Fourth, values cascaded automatically between steps. The SSH key path was pulled from a directory listing, confirming the file existed. The AWS secret ID came from a ListSecrets response captured 20 seconds before retrieval. The database password flowed from the .pgpass read into the connection string without any human intervention. The agent was feeding its own prior output into every subsequent action, live and without direction.
As Sysdig’s Sr. Director, Michael Clark, stated plainly, attackers are not being replaced by AI; they are replacing their scripts with it.
Canadian Impact and the CCCS Angle
For Canadian organizations, this attack pattern presents a direct and urgent risk. Marimo has seen rapid adoption in Canadian post-secondary institutions, financial services data teams, and federal and provincial analytics environments. Any of these running marimo with internet-facing terminal access and unrotated cloud credentials are within the scope of exactly this attack chain.
Under PIPEDA and provincial privacy legislation, a database exfiltration of this nature — especially one involving credentials — triggers mandatory breach notification requirements if personal information is involved. The speed of this attack, from initial access to full database dump in under two minutes, means that by the time a traditional signature-based detection system fires an alert, the data is already gone.
The Canadian Centre for Cyber Security (CCCS) has consistently advised organizations to move toward behavior-based detection and zero-trust architecture. This incident is a concrete illustration of why those recommendations carry urgency. Signature-based tools fail against LLM-driven attackers because every command sequence is freshly generated. There is no repeatable fingerprint to match.
Canadian small and medium-sized businesses using AWS with notebook-based data science workflows are particularly exposed. Cloud-first SMBs often store SSH keys and database credentials in Secrets Manager or environment files without enforcing least-privilege IAM policies, the exact configuration this attack chain exploited.
Why Traditional Defenses Fall Short Against LLM-Driven Attackers
Conventional intrusion detection relies on matching known patterns: the same command sequence, the same probe order, and the same tool signatures. An LLM agent produces none of those. It constructs new commands for every environment it encounters, reasons from general knowledge to fill gaps, and distributes its traffic to defeat IP-based correlation.
The detection strategy must shift from “what commands were run” to “what was accomplished.” Credential access, cloud API enumeration, and lateral movement to internal databases; these behavioral outcomes remain consistent regardless of how the underlying commands are written. Runtime threat detection platforms that model behavior rather than syntax are the appropriate countermeasure.
Key Takeaways
- The first confirmed LLM-agent-driven intrusion completed a full post-exploitation chain from exposed notebook server to internal database dump in under two minutes.
- CVE-2026-39987 in Marimo allows unauthenticated remote code execution via a single WebSocket request and is actively being exploited.
- The attacker used Cloudflare Workers as distributed egress infrastructure, fanning 12 AWS API calls across 11 IPs in 22 seconds to defeat cloud-native alerting.
- Four technical markers confirm LLM agent involvement: adaptive schema reasoning, embedded Chinese planning comments, machine-structured command output, and automatic value chaining between steps.
- Canadian organizations in data science, finance, education, and government running Marimo or similar notebook platforms are directly in scope for this attack pattern.
- Under PIPEDA, a successful database exfiltration involving personal data triggers mandatory breach notification requirements, and at this attack speed, organizations may not detect the breach before the data is already exfiltrated.
- Signature-based detection is insufficient against LLM-driven attackers; behavior-based runtime detection aligned with CCCS guidance is required.
What You Should Do Now
- Patch marimo immediately. Update to version 0.23.0 or later. If upgrading is not immediately possible, restrict or disable access to the
/terminal/wsWebSocket endpoint at the network layer. - Audit internet-facing notebook servers. Scan your environment for any marimo, Jupyter, or similar notebook instances directly reachable from the internet without authentication controls.
- Rotate all credentials on potentially exposed instances. Any Marimo server that was internet-accessible before patching should be treated as compromised. Rotate AWS access keys, SSH private keys, database passwords, and any secrets stored in environment files or Secrets Manager.
- Enforce least-privilege IAM policies on cloud credentials. AWS credentials accessible from notebook environments should carry only the minimum permissions required. They should never have read access to Secrets Manager unless operationally necessary.
- Shift detection to behavior-based tooling. Implement runtime threat detection that flags behavioral patterns, credential enumeration, lateral movement, and bulk database reads rather than relying solely on command signatures or IP blocklists.
- Review your PIPEDA breach notification readiness. Given the sub-two-minute exfiltration timeline documented in this incident, organizations must have pre-defined breach response procedures that do not depend on real-time human detection.
- Consult CCCS advisories. The Canadian Centre for Cyber Security publishes actionable guidance on cloud security and zero-trust architecture that directly addresses the exposure class demonstrated in this attack.
Indicators of Compromise (IoCs)
| Type | Indicator | Description |
|---|---|---|
| IP Address | 157[.]66[.]54[.]26 | Origin IP for marimo terminal sessions (AS141892, Indonesia) |
| IP Range | 104[.]28[.]0[.]0/16 | Cloudflare Workers egress pool (AS13335) used for AWS API calls and SSH sessions |
| IP Address | 104[.]28[.]162[.]160 | Cloudflare Workers IP used in schema enumeration and PostgreSQL dump |
| IP Address | 104[.]28[.]165[.]251 | Cloudflare Workers IP used in the targeted credential table dump |
| IP Address | 104[.]28[.]165[.]169 | Cloudflare Workers IP used in credential-file search |
| IP Address | 104[.]28[.]157[.]50 | Cloudflare Workers IP used in SSH-key enumeration |
| CVE | CVE-2026-39987 | Critical marimo terminal WebSocket RCE (attack chain entry point) |
De-fang indicators only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.