LLM Agent: Four Pivots in Two Minutes

Two minutes. Four pivots. One database dump.

That’s the timeline Sysdig’s threat research team documented in a live intrusion on May 10. The attacker didn’t follow a script. They handed the wheel to an LLM agent and watched it work.

What Sysdig documented

CVE-2026-39987 is an RCE vulnerability in marimo, an open-source reactive Python notebook server used widely in AI and data science teams. It hit the CVE database and was exploited within 10 hours. Not unusual by 2026 standards — Mandiant’s latest threat intelligence data shows 28.3% of disclosed CVEs are exploited within 24 hours. The exploitation speed isn’t the story. What happened after is.

Once inside the marimo environment, the attacker deployed an LLM agent as the post-exploitation driver. Not a script. Not Metasploit modules. An agent that read command output and decided the next step, the way a human operator would, only considerably faster.

The chain it ran: RCE via the CVE, then AWS credential harvest from instance metadata, then a Secrets Manager query to retrieve an SSH key for the bastion host, then lateral movement to an internal subnet, then a PostgreSQL database dump. Four pivots. Under two minutes, start to finish.

Sysdig’s researchers note the agent made independent decisions at each step based on what it received back. It wasn’t operating from hardcoded commands for a specific environment. It was reading output and adapting. That distinction matters.

The detection timeline problem

Standard security operations are built on an assumption of dwell time. SIEMs are tuned to look for patterns across hours. Alert triage queues run at mean-time-to-acknowledge measured in minutes. Incident response playbooks assume the attacker is somewhere in the network while your team figures out what happened.

Sub-two-minute full-chain compromise punctures all of that.

If your mean-time-to-acknowledge for a critical alert is eight minutes — which is considered good performance in most SOC benchmarks — the database is already out the door before an analyst has opened the ticket. The window between exploitation and objective completion is now shorter than your response cycle. Human-in-the-loop review doesn’t fit in that window.

The implication is uncomfortable. Detection at initial access becomes the only viable intervention point. Once the agent is executing, automated containment (network isolation, credential revocation, sandbox) has to trigger on high-confidence indicators in seconds, not minutes. Most security teams aren’t configured for aggressive automated response, partly because automated response carries its own operational risk. False positive isolation of a production service is its own incident.

Which means the pressure falls on initial access detection quality. Getting that first alert right — fast, high-confidence, low false-positive — is now the whole game.

Why notebook servers specifically

Marimo isn’t a random target. AI and data science notebook environments have unusually high credential density. Cloud access keys, database connection strings, API tokens for external services, model registry credentials — they’re present by design because notebooks need them. That’s the use case, not a misconfiguration.

For an LLM agent doing post-exploitation, a notebook environment is an efficient starting point. One code execution vulnerability and you’re adjacent to a wide variety of high-value credentials, often with minimal authentication barriers between the notebook execution environment and those credentials.

Notebook server security also tends to lag behind production application security in most organisations. Partly because it’s framed as developer or research tooling rather than production infrastructure. Partly because the teams running notebook environments are data scientists and ML engineers, not security-focused infrastructure teams. If your notebook servers are internet-facing, or reachable from segments that could be compromised, they warrant the same security posture as production APIs.

The patch for CVE-2026-39987 is straightforward. Apply it. While you’re there: audit whether notebook execution environments are scoped to the credentials they actually need, or whether someone used a high-privilege role because it was convenient.

What the trajectory looks like

The specific vulnerability will be patched and the conversation will move on. The more durable signal in the Sysdig findings is what the attacker chose to do after gaining code execution.

Scripted post-exploitation tooling requires anticipating the environment. If the environment doesn’t match the script’s assumptions, you’re stuck. Human attackers adapt, but the adaptation takes time and expertise. An LLM agent adapts immediately, interpreting whatever the environment returns and continuing from there. That’s a qualitative change in the capability ceiling of automated post-exploitation — and it’s now confirmed in live attacks, not just research papers.

The detection question this creates isn’t whether your EDR flagged a known malware signature. The question is whether your coverage on credential access from notebook environments, anomalous Secrets Manager queries, and unusual bastion SSH patterns is fast enough to matter. In this case, the threshold was two minutes. That’s the benchmark you’re working against now.

References

• 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
• Cybersecurity News — Hackers Use LLM Agent to Move From Marimo RCE to Internal Database in Four Pivots
• Security Affairs — CVE-2026-39987: Marimo RCE exploited in hours after disclosure
• Mandiant — M-Trends 2026: Time-to-Exploit and Dwell Time Data
• MITRE ATT&CK — T1078: Valid Accounts
• MITRE ATT&CK — T1555: Credentials from Password Stores
• AWS — Security best practices for AWS Secrets Manager