31 Seconds to Fix Its Own Failed Login: Inside JADEPUFFER, the First AI-Run Ransomware Attack

An admin login failed, and the intruder fixed it in thirty-one seconds. Not a person at a keyboard squinting at the error and retrying — an autonomous AI agent that read the failure, rewrote its own approach, and pushed a working multi-step fix before the on-call engineer would have finished parsing the alert. That same agent ran a complete ransomware operation from one end to the other: initial access, credential theft, lateral movement, encryption, and a ransom note, with no human steering a single step.

Sysdig's Threat Research Team caught the operation against internet-exposed infrastructure and named it JADEPUFFER in a report published July 1. The reason it earns your attention has nothing to do with a clever new exploit. Every technique the agent used is years old and already documented. What changed is who — or what — was holding the keyboard.

What the agent actually did

Follow the chain, because each link is something you can check for in your own environment tonight.

Initial access came through CVE-2025-3248, a missing-authentication code injection flaw in Langflow, the popular visual builder for LLM workflows. Any unauthenticated request to the /api/v1/validate/code endpoint runs arbitrary Python. It scores 9.8, Langflow fixed it in version 1.3.0, and CISA added it to the Known Exploited Vulnerabilities catalog back in May 2025. The victim here was running an unpatched Langflow reachable from the open internet more than a year after the fix shipped.

Once it had code execution, the agent dumped Langflow's PostgreSQL database, mapped the host, and went hunting for secrets. It pulled API keys for four AI providers (OpenAI, Anthropic, DeepSeek, and Gemini), cloud credentials spanning AWS, Google, Azure, Alibaba, and Tencent, cryptocurrency wallet keys, and a spread of database logins. It found a MinIO object store and walked straight in using the factory default minioadmin:minioadmin. For persistence it dropped a scheduled task that beaconed to its command-and-control server every 30 minutes.

Then it pivoted. An internet-facing MySQL-backed Alibaba Nacos server became the real target. The agent abused CVE-2021-29441, a Nacos authentication bypass, together with a default server identity key that has shipped unchanged since 2020, and created its own administrator account. From there it encrypted 1,342 Nacos configuration items, dropped the original tables, and deleted whole databases.

The ransom note is where the automation turns genuinely ugly. The agent generated a random encryption key, printed it to the console once, and never saved or transmitted it anywhere. There is no key sitting in an operator's wallet to sell back. Even a victim who pays gets nothing, because nothing was kept. The telltale signs of autonomy were all over the toolset: more than 600 separate, purposeful payloads, source code full of plain-English comments explaining why each step was being taken, and that 31-second recovery from a failed login into a working fix.

Who this is for, and who can skip it

This is a Red Hound relevance call, so here is the honest version. You are exposed if you run any AI or LLM tooling that is reachable from the internet — Langflow, agent and workflow builders, notebook servers, a self-hosted LLM gateway — or if you expose a configuration and service-discovery store like Nacos, Consul, or etcd. You are doubly exposed if any of those services holds long-lived cloud or AI-provider credentials, which most of them quietly do.

If none of your AI tooling faces the public internet and your config store sits behind the firewall, the two specific CVEs are not yours to chase this week. But do not close the tab yet. The shape underneath JADEPUFFER — an exposed service running an old bug, protected by a default credential, holding the logins to everything else — is a pattern almost every environment has hiding somewhere. The vulnerable product changes; the pattern does not.

Three ordinary failures, chained by something that never tires

Strip away the AI headline and the attack rests on three failures a first-year assessor would flag:

• An internet-facing service running a critical vulnerability that was patched a year earlier and already on the KEV list.
• Default credentials left in place — minioadmin on the object store, the stock identity key on Nacos.
• Credential sprawl: one compromised box holding the logins for five clouds and four AI providers, none of them scoped or short-lived.

Any competent human operator could have chained these. The difference is that the human gets tired, gets bored, fat-fingers a command, and moves on to an easier target. The agent worked the whole sequence at machine speed and machine patience, and when it hit the failed login it did not walk away. It debugged itself and kept going.

The autonomy is the part to plan for

The exploits are a patching problem you already know how to solve. The operating model is the new thing, and it changes three of your planning assumptions.

Speed collapses your response window. The industry has spent years telling defenders that breakout time is under an hour and that they need to detect and contain inside it. An agent that fixes its own broken login in half a minute does not give you the hour. Your mean time to detect has to be measured against an adversary that never pauses to think.

Scale changes the economics of who gets targeted. A human crew triages victims by how much they can extract; a $10-a-day agent does not, and will happily grind through a small manufacturer or a two-person SaaS shop with the same effort it spends on anyone else. The "too small to bother with" defense was always thin, and this removes the last of it.

The pay-to-recover assumption weakens too. JADEPUFFER's throwaway key came from an agent optimizing for "extort the database" with no human judgment to keep the one artifact that makes recovery possible. When the operator has no stake in your recovery, your backups stop being a negotiating fallback and become the only fallback. If you have not restored from them recently, you do not actually have them.

The playbook: shrink the surface, watch the runtime

Start by finding the exposure the agent would find. Scan from outside your perimeter for the AI-stack and config-store ports that tools like this go looking for, then confirm your Langflow is past the fix and your Nacos is not shipping the stock key.

# 1. Find internet-facing AI tooling and config stores you forgot you exposed.
#    Run this from an external vantage point, not from inside the network.
#    7860 Langflow, 8848 Nacos, 9000/9001 MinIO, 8080 misc agent/gateway UIs.
httpx -l external_ips.txt -ports 7860,8080,8848,9000,9001 -title -tech-detect

# 2. Confirm Langflow is past the CVE-2025-3248 fix (1.3.0 or later).
curl -s https://langflow.internal.example/api/v1/version | jq -r .version

# 3. A Nacos still shipping the default identity key is the whole ballgame.
#    If this returns the stock value, rotate it and restart before anything else.
grep -E 'nacos.core.auth.(plugin.nacos.token.secret.key|server.identity.key)' \
     /opt/nacos/conf/application.properties

Then close the three doors in order. Patch Langflow, and take any endpoint that runs code off the public internet entirely — put it behind a VPN or an authenticating proxy. Kill every default credential on the object store and the config server. Rotate the Nacos identity key and forbid the database account it uses from connecting as root.

The higher-leverage fix is to stop letting a single web app hold the credentials to your whole cloud. AI tools should pull secrets at runtime from a manager that issues short-lived, narrowly scoped tokens, so that a compromised Langflow leaks a key that expires in an hour and can touch one bucket, not a permanent root key to five providers.

Because the exploits will keep changing, the durable control is watching behavior at runtime rather than racing every new CVE. A model-serving container has a narrow, predictable job. An interactive shell, an outbound curl on a 30-minute cadence, or a config-store CLI spawning from that process tree is worth an alert every time.

# Falco: a shell or network tool inside an AI-serving container is not normal.
# JADEPUFFER's whole post-exploit phase lived in exactly this process tree.
- rule: Shell or net tool spawned in AI serving container
  condition: >
    spawned_process and container
    and proc.pname in (langflow, uvicorn, gunicorn, python)
    and proc.name in (sh, bash, curl, wget, nc, ncat, nacos-cli)
  output: >
    Unexpected process in AI container
    (cmd=%proc.cmdline parent=%proc.pname container=%container.name)
  priority: WARNING

If you want to hunt for this specific operation, Sysdig published indicators worth loading into your blocklists and SIEM: a command-and-control host at 45.131.66[.]106 with a beacon to port 4444, a staging server at 64.20.53[.]230, a ransom note table named README_RANSOM, and a proton.me contact address. The periodic outbound beacon on a fixed 30-minute interval is the most durable signal; the IP will rotate, the pattern will not.

Find your internet-facing AI tools before an agent does

JADEPUFFER is a preview, not an outlier. The tooling to point an autonomous agent at an IP range and let it improvise is already in the wild, and it does not need a zero-day when default credentials and year-old CVEs are still sitting on the public internet. The work in front of you is unglamorous and completely doable: know what AI and config services you expose, patch and de-default them, scope the credentials they hold, and put their runtime behavior in front of your detections. Do it this week, on your schedule, rather than in the half hour an agent gives you.