Dateline: July 7, 2026
The First Ransomware Attack Run Entirely by an AI Is Here
For years, security folks warned this day would come. Now it has. Researchers at Sysdig say they found the first real ransomware attack run from start to finish by an AI model, with no human writing the steps. They call the attacker JadePuffer.
What Happened?
JadePuffer broke into an internet-facing Langflow server. Langflow is an open source tool people use to build AI apps. The way in was CVE-2025-3248, a critical flaw that lets anyone run code on the machine without logging in.
From there the AI worked its way toward the real prize: a separate internet-exposed server running a MySQL database and an Alibaba Nacos config service. It listed the database contents, pulled out selected data, wiped the database, and left a note demanding payment to get the stolen files back.
Every payload came in as Base64-encoded Python pushed through the Langflow flaw. The first machine it hijacked became the launch pad for hitting the final target.
What’s the Impact?
None of these moves were new. Sysdig and outside experts agree on that. Exploiting an exposed service, stealing credentials, moving sideways, abusing default settings, and destroying databases are all standard playbook stuff. Johan Edholm of Detectify called it more evolution than invention.
The shift is who strung it all together. An AI model chained recon, credential theft, lateral movement, persistence, and destruction into one clean operation. Normally that mix points to a skilled human. Now it points to a capable model.
Two details gave the AI away.
- First, its own code was self-narrating, packed with plain-English reasoning and target notes that human hackers rarely bother to write but AI produces by habit.
- Second, it fixed its own mistakes at machine speed. When one login failed, JadePuffer refined its approach and got in. That correction took 31 seconds.
Worth noting: back in August, researchers thought they had found the first AI-driven ransomware, called PromptLock. It turned out to be a lab proof of concept from NYU, not a real attack. JadePuffer looks like the genuine article.
The bigger worry is spread. Edholm expects early adopters to be crews who already know how to wire AI models to offensive tools and stolen credentials. Once that tooling gets packaged and reusable, weaker operators will pick it up too. Criminal groups move fast because no procurement or compliance slows them down.
How to Avoid This Sysdig and the experts point to a clear set of steps:
- Patch Langflow to a version that fixes CVE-2025-3248, and keep code-execution endpoints off the public internet.
- Do not link provider API keys or cloud credentials to the AI-orchestration server they run on. Keep secrets in a proper manager.
- Harden Nacos by changing default signing keys and keeping it off the internet.
- Lock down internet-facing databases with strong passwords and IP restrictions on management ports.
- Move from quarterly snapshots to continuous visibility. An automated attacker can go from discovery to impact in minutes, so gaps between scans are dangerous.
How Secure.com Would Have Stopped JadePuffer Before the Ransom Note
Here is the part that stings. Secure.com would have found the internet-facing Langflow server, the CVE, and the open MySQL database before JadePuffer ever touched them. The break-in started with an exposed asset that a continuous exposure scan flags on day one. The attacker only won because nobody was looking on the days between scans.
Walk the attack back one stage at a time and you can see where it breaks.
incident teardown / ai-orchestrated ransomware
An AI ran the entire ransomware attack. No human wrote the steps.
Sysdig’s teardown of JadePuffer — the first real ransomware campaign orchestrated end-to-end by an LLM. Initial access came through CVE-2025-3248, a critical RCE in an internet-exposed Langflow server. Every payload was Base64-encoded, self-narrating Python.
CVE-2025-3248 to run code remotely.publicly_accessible) and the CVE correlated against KEV / EPSS — a publicly-exposed asset with known exploits, flagged before the breach.cspm · pre-breachMySQL 3306 open to 0.0.0.0/0 is high; publicly-reachable database access is critical.cspm misconfigThis is the whole case for continuous over quarterly. A snapshot every three months leaves a hole an attacker can drive through for weeks. Continuous CTEM, adversarial exposure validation, and the Purple loop close that hole because they never stop looking. That is the difference between reading about a breach and preventing one.
