Did an AI Agent Really Run a Ransomware Attack by Itself?
Mostly, but not entirely. Security firm Sysdig documented an attack it calls JadePuffer, where an AI agent carried out the full technical intrusion against a company's servers — scanning, stealing credentials, moving across systems, and encrypting a production database — on its own, correcting a failed login in 31 seconds along the way. But Sysdig's own writeup is clear that a human attacker still chose the victim, set up the infrastructure the agent reported back to, and handed it a stolen database password before any of that started. The AI didn't decide to attack anyone. It automated the slow, skilled part of a break-in that a human had already set up — which is a narrower, more useful thing to understand than "AI went rogue."
What actually happened, in order
The target was an internet-facing server running Langflow, an open-source tool people use to build AI workflows by connecting pieces together visually. That server had a known bug — CVE-2025-3248, a flaw in Langflow's code-validation endpoint that lets anyone reach it over the internet and run their own code, no login required. Langflow patched it in version 1.3.0, and CISA added it to its list of known-exploited vulnerabilities back in May 2025. This particular server was still running the vulnerable version more than a year later.
From there, an AI agent took over and ran the rest of the operation:
- Scanned the compromised machine and mapped what else it could reach
- Harvested API keys (OpenAI, Anthropic, DeepSeek, Gemini), cloud credentials, and database logins sitting on the server
- Found a MinIO storage system still set to its factory default login —
minioadmin/minioadmin— and pulled files from it - Set up a scheduled task pinging an attacker-controlled server every 30 minutes to stay in
- Pivoted to a separate, internet-facing production server running MySQL and a service called Nacos
- Logged into that server's database as root, using a password it had been given rather than one it guessed
- Broke into Nacos itself using a second, older bug (CVE-2021-29441) and a default security key the server owner had never changed
- Encrypted 1,342 configuration records, deleted the originals, dropped several database tables containing customer and user data, and left a Bitcoin ransom note
All told, the agent executed more than 600 distinct steps. The detail Sysdig flagged as the clearest sign of genuine reasoning, rather than a fixed script running on autopilot: one login attempt failed, and the agent diagnosed the problem and tried a working fix 31 seconds later — the kind of quick, contextual troubleshooting a script can't do but a person, or something reasoning like one, can.
What was automated — and what still needed a person
The headlines this week mostly ran with "AI ran a ransomware attack by itself," and technically, the intrusion itself is a fair description of that. But Sysdig's own research draws a more precise line, and it's the part worth actually remembering:
| Handled by the AI agent | Still required a human, beforehand |
|---|---|
| Scanning the server and mapping the network | Choosing which organization to target |
| Harvesting API keys, cloud credentials, and logins | Obtaining the stolen MySQL root password, from an earlier, separate breach |
| Exploiting the Nacos bug and forging a login token | Setting up the command-and-control server the agent reported back to |
| Encrypting records, dropping tables, writing the ransom note | Building the staging infrastructure the whole operation ran from |
| Adapting in real time when a step failed | Deciding to launch the operation at all |
What actually changed: not that AI can now decide to attack someone — it can't, and didn't here. What changed is that the slow, expert-level hours a break-in like this used to take a skilled human operator can now be handed to an agent that works faster, doesn't get tired, and doesn't make careless typos. The strategic decisions are still entirely human. The labor-intensive execution isn't, anymore.
Why this matters even if you'll never touch Langflow
Every entry point in this story is a preventable, unglamorous security basic — not some exotic new AI-specific hole. An unpatched bug that's been publicly known and fixable for over a year. A storage system still on its out-of-the-box password. A security key nobody ever rotated. None of that is new. What's new is that all three can now be found and chained together by something that works around the clock, doesn't need to be an expert, and costs whatever it takes to run a few hundred agent steps — which, if the attacker is using stolen API access, can be close to nothing.
That's the actual shift worth paying attention to: the technical skill floor for turning an exposed, unpatched, default-credentialed server into a real breach has dropped substantially. The forgotten test server, the internet-facing tool nobody updated, the storage bucket still on its default login — those used to be a risk mainly if a skilled person happened to find them. Now an agent can do the finding and the exploiting both, on a timeline measured in minutes rather than a skilled attacker's working hours.
The one practical question this raises for any AI tool you use
This isn't a reason to be afraid of AI agents generally — the tool that got broken into here (Langflow) wasn't attacked because it uses AI, it was attacked because it was an unpatched, unauthenticated service sitting on the open internet. That's the same lesson we drew from OpenClaw's 2026 exposure problems: the risk lives in whether a piece of software is reachable from outside your machine and locked down by default, not in whether it happens to involve AI.
So the question to ask of any agent, assistant, or automation tool you're evaluating isn't "could AI hack me" — it's narrower and easier to actually check:
- Does it run as a server reachable from the internet — one you or your IT provider has to remember to patch — or does it just run on your own machine with nothing listening for outside connections?
- Is authentication on by default, or is it a setup step you (or whoever installed it) could forget?
- Does it depend on other services (storage, databases, key stores) that ship with default passwords you're expected to change yourself?
If the honest answer to the first question is "yes, it's a server, and someone has to keep it patched," that's not automatically disqualifying — plenty of legitimate business tools work that way. It just means patching and credential hygiene aren't optional maintenance for that tool; they're the entire security model.
Where bots.team stands, precisely
bots.team's bots run inside a desktop app on your own Mac or Windows machine. There's no server component sitting on the internet waiting for a connection, authenticated or not — nothing with a public IP address to leave unpatched, and nothing shaped like the exposed Langflow instance in this story. That's a structural difference, not a setting you have to remember to turn on.
To be precise rather than to oversell it: bots.team's bots do reach out to Anthropic's Claude API to do their reasoning, the same outbound call every Claude-based agent tool makes, including ones built on Langflow itself. JadePuffer's story is entirely about an inbound door being left open — a service reachable from the outside, running unpatched. bots.team doesn't have that inbound door to begin with, which is a different and simpler thing to get right than "remember to patch it."
FAQ
Did the AI agent decide to attack the company on its own? No. Sysdig's own research is explicit that a human attacker chose the target, provisioned the infrastructure, and supplied a stolen database password before the agent did anything. The agent handled the technical execution — scanning, credential theft, lateral movement, encryption — not the decision to attack.
Is JadePuffer the first AI-related cyberattack? It's the first documented case where an AI agent ran a complete ransomware operation — from initial access to database destruction — end to end, without a human directing each individual step. AI-assisted attacks (phishing content, scanning tools, code generation) have existed for a while; this is different in scope, which is why Sysdig gave it its own name.
What is Langflow, and do I use it? Langflow is an open-source tool developers use to build AI workflows visually, typically self-hosted on a company's own server. If you're not technical and don't manage your own servers, you almost certainly don't run it — the exposure here affects people who self-host developer tools, not everyday users of consumer AI apps.
Should I stop using AI agent tools because of this? Not based on this story specifically — the vulnerability was in an exposed, unpatched server, not in the concept of AI agents. The useful takeaway is to ask any tool you use whether it runs as an internet-reachable service and whether authentication is on by default, the same question this exact scenario turned on.
Sources: Sysdig Threat Research Team's JadePuffer disclosure (July 2026), The Hacker News and CSO Online's independent technical breakdowns, CISA's Known Exploited Vulnerabilities catalog, and bots.team's own product architecture. Figures current as of July 2026.