An LLM Agent Just Ran a Live Cyberattack

Researchers just documented the first confirmed cyberattack driven entirely by an LLM agent — no human operator, fully autonomous, start to finish in under an hour.

This isn't a lab demo. It happened in the wild, on May 10, 2026. Sysdig's Threat Research Team caught it live.

What happened

The attacker compromised an internet-reachable marimo notebook via CVE-2026-39987, extracted two cloud credentials from the compromised host, replayed them through a fanned-out egress pool to retrieve an SSH private key from AWS Secrets Manager, and used that key to drive eight short SSH sessions against a downstream SSH bastion server. The bastion phase exfiltrated the schema and full contents of an internal PostgreSQL database in under two minutes. Sysdig

CVE-2026-39987 allowed unauthenticated remote code execution in Marimo versions prior to 0.23.0. If you're running marimo notebooks exposed to the internet and haven't patched, that's your first problem. Hendryadrian

The full attack chain — from initial exploit to database dump — took just over an hour.

What made this different

Traditional attacks are scripted. The attacker writes a playbook, runs it, and adapts manually if something goes sideways. This one didn't work like that.

Unlike traditional scripted attacks, the post-compromise activity was dynamically generated by an LLM agent that analyzed outputs and decided next steps on the fly. GBHackers

Tasks that previously required continuous manual analysis and decision-making were delegated to an AI system, allowing attackers to move faster and pivot more efficiently within compromised environments. Security Magazine

Sysdig identified four indicators pointing to an LLM agent running the show. One of the clearest: the attacker improvised a database dump without prior knowledge of the schema — something that requires real-time reasoning, not a canned script. Cyber Security News

Why this matters for developers

If you're building on cloud infrastructure — and especially if you're running anything AI-adjacent like notebooks, sandboxes, or agent runtimes — this attack pattern is aimed directly at your stack.

The attack chain here is almost embarrassingly clean:

1. Exposed marimo notebook with an unpatched RCE vulnerability
2. Cloud credentials sitting in the environment
3. SSH key in AWS Secrets Manager (reachable with those credentials)
4. Internal database, unprotected once the bastion was cleared

Every one of those steps is a failure that's common in dev and staging environments. Credentials in env files, exposed internal tooling, SSH keys stored in Secrets Manager with overly broad access — this isn't exotic. It's the default mess.

This approach uses fanned-out egress pools, which breaks traditional source-IP correlation and makes detection significantly harder for defenders relying on rate-limiting or IP-based anomaly detection. GBHackers

The bigger picture

This isn't an isolated incident. CrowdStrike data puts average attacker breakout time at 29 minutes, alongside an 89% increase in AI-enabled adversary operations. Tech Times

The Sysdig incident is the first documented case of an LLM agent running post-exploitation autonomously — but it won't be the last. The tooling to do this is accessible. The vulnerabilities to exploit are everywhere. And the agent handles the parts that used to require a skilled attacker sitting at a keyboard.

I've written before about how AI agents deleted a production database without any human intervention — that was an accident. This was intentional. The capability is the same.

What you should actually do

Patch marimo now. CVE-2026-39987 affects all versions prior to 0.23.0.

Beyond that:

• Don't expose notebooks or internal tooling to the internet without auth
• Rotate credentials regularly and don't leave them in env files
• Audit what's sitting in AWS Secrets Manager and who can reach it
• Implement least-privilege IAM — an SSH key in Secrets Manager shouldn't be reachable from a dev notebook
• If you're not monitoring lateral movement in your cloud environment, start

The attacker here didn't do anything novel. They just let the LLM figure out the path. That's the shift.

Source: Sysdig Threat Research Team