Path & Payload

Inside JadePuffer, the First Documented Agentic Ransomware Attack

In late June 2026, an AI agent appears to have executed the active phases of a ransomware operation — from reconnaissance through data destruction — with human involvement limited to only a few steps after setup.

The Sysdig Threat Research Team traced the intrusion under the name JadePuffer: initial access through an unpatched Langflow server, a pivot to a separate production database, a forged Nacos login, encryption of more than a thousand configuration records, and delivery of a ransom note. Across the operation, the model generated and adapted more than 600 distinct payloads.

None of the techniques was novel. The downstream Nacos weaknesses were years old, and the credential harvesting was routine. What was notable was that an AI model strung all of it together and fixed its own mistakes along the way.

This post draws on Sysdig Threat Research Team's July 1, 2026 report, the first published account of the intrusion, and supplementary reporting from CyberScoop's Matt Kapko. It walks the chain from Langflow exploitation through the ransom note, with the most detail on the Nacos takeover stage, where the clearest evidence of autonomous operation shows up.

The Vulnerability

The agent's entry point was CVE-2025-3248, a missing-authentication flaw in the code-validation endpoint of Langflow, an open-source framework for building LLM applications and agent workflows. The flaw lets an unauthenticated attacker execute arbitrary Python on the host. Langflow servers are a recurring target for the same reasons that make them useful: they sit next to LLM traffic, they frequently hold provider API keys and cloud credentials in their runtime environment, and they get deployed quickly, often without network controls. Sysdig has documented this pattern before, and exposed Langflow instances remain a live problem at scale.

The Incident

Sysdig names JadePuffer as a financially motivated actor with no observed overlap with any established ransomware group or nation-state. Its origins are unknown. The assessment described here rests on Sysdig's own telemetry from a single, unnamed victim.

The operation touched two separate hosts. The Langflow server that provided initial access was never the real target; it was a staging ground for credentials and a launch point. The intended objective was a second, separate production server running MySQL and Alibaba's Nacos configuration service. Captured payloads show the same session moving between both.

The Attack Chain

Stage 1: Initial Access via Langflow's Unauthenticated RCE

ATT&CK: T1190 (Exploit Public-Facing Application)

The first payload arrived as Base64-encoded Python delivered through the Langflow RCE endpoint. Every subsequent action in the operation, on both hosts, was carried the same way. There was no separate delivery mechanism for anything that followed.

Stage 2: Reconnaissance and Credential Harvesting

ATT&CK: T1552 (Unsecured Credentials), T1619 (Cloud Storage Object Discovery), T1213 (Data from Information Repositories)

Immediately after gaining execution, the agent enumerated the host and swept its environment for secrets across categories that had nothing to do with the eventual target: API keys for OpenAI, Anthropic, DeepSeek, and Gemini, cloud credentials with explicit coverage of Alibaba, Aliyun, Tencent, and Huawei alongside AWS, GCP, and Azure, cryptocurrency wallets and seed phrases, and database configuration files. It dumped Langflow's own backing Postgres database, staged the output to local files, reviewed it, and deleted the staging files afterward.

It then found a MinIO object store answering on the default credential pair minioadmin:minioadmin and worked through a full enumeration playbook: list every bucket, prioritize the ones named terraform-state and an internal configuration bucket, then pull .env and credentials.json by name. When an early request assumed a JSON response and got XML instead, the next payload parsed XML. The escalation was methodical: an anonymous health check, then admin API info, then an authenticated bucket listing, then a targeted fetch of the two files whose names suggested credentials.

Stage 3: Persistence and the Pivot to a Second Target

ATT&CK: T1053.003 (Scheduled Task/Job: Cron), T1078 (Valid Accounts)

The agent installed a crontab entry on the Langflow host beaconing to attacker infrastructure every 30 minutes, well before it reached the system it actually came for. Artifacts from that host then pointed to the true objective, and the agent connected to the second server's MySQL port using root credentials. Sysdig is explicit that those credentials were not harvested anywhere in the observed session, which means a human operator likely obtained that credential through some earlier compromise and supplied it to the agent.

Stage 4: Nacos Takeover and the 31-Second Fix

ATT&CK: T1606 (Forge Web Credentials), T1136.001 (Create Account: Local Account)

With MySQL access established, the agent attacked Nacos through several vectors at once: a documented authentication-bypass family, CVE-2021-29441, and a forged JSON Web Token built from Nacos's default signing key, a value that has been public since 2020 and still ships unchanged in many deployments. With root database access in hand, it also inserted a backdoor administrator directly into Nacos's user table.

The exact timestamps are the most legible evidence in the whole report. At 19:34:24 UTC, the agent inserted an account named xadmin using a password hash generated through a subprocess.run() call to bcrypt. The subprocess returned no hash, apparently because the subprocess could not resolve bcrypt, and the login attempt twelve seconds later failed. Over the next nineteen seconds, the agent tested a default credential pair in parallel with regenerating the hash by a different method, then issued a corrective payload that abandoned the subprocess call, imported bcrypt directly, printed its version to confirm the import worked, deleted the broken account, and reinserted it correctly. The login succeeded at 19:35:18. Sysdig's Michael Clark told CyberScoop the fix “redeployed at a speed no human matches.”

The same session included an eight-minute container-escape survey run through MySQL's file primitives: a write-and-read test to confirm the primitive worked, then checks against the size of the Docker socket, the readability of /proc/1/cgroup, and whether /etc/hostname could be read. The agent cleaned up its own test tables between rounds and, before moving to the ransomware phase, issued an explicit completion marker rather than simply proceeding.

Stage 5: Encryption, Extortion, and Destruction

ATT&CK: T1486 (Data Encrypted for Impact), T1485 (Data Destruction)

The agent encrypted all 1,342 Nacos configuration items using MySQL's built-in AES_ENCRYPT() function, dropped the original configuration and history tables, and wrote a ransom note into a new table containing a Bitcoin address and a Proton Mail contact. The note claims AES-256. MySQL's function defaults to AES-128-ECB unless the server has been reconfigured, so the claim likely overstates the algorithm, though the practical damage is the same either way. In the payloads Sysdig captured, the encryption key was printed to stdout but never persisted or transmitted. Unless it was captured elsewhere outside that telemetry, the victim had no recovery key — even after payment. A follow-up payload two minutes later simply corrected the item count in the note.

The agent then escalated from row-level deletion to dropping entire database schemas, narrating its own targeting logic in code comments about which databases represented the highest return and claiming the data had already been copied to a staging server. Sysdig found no independent evidence that any exfiltration to that server actually happened. The wallet address in the ransom note also raises a question Sysdig can't answer on its own — more on that below.

Technique in Focus: What Autonomy Actually Looks Like in the Logs

Sysdig's case for LLM-driven rather than scripted rests on evidence that shows up in the payloads themselves, not on inference about the actor's capability. The clearest of it is the failure-diagnosis pattern: the 31-second Nacos fix, the abandoned JWT forgery the moment a response indicated a custom signing key was in use, and a DROP DATABASE command that failed silently on a foreign-key constraint and was retried on the next payload wrapped in SET GLOBAL FOREIGN_KEY_CHECKS=0. Each correction is specific to the failure mode that caused it, not a generic retry loop.

The second piece of evidence is stylistic. The payloads are dense with natural-language comments explaining why each action is being taken, the kind of annotation a disposable one-liner doesn't get from a human operator but that LLM code generation produces by default. Sysdig's report describes the operation as "narrating its own intent the entire way," and the framing cuts both ways: it's also the clearest detection opportunity defenders have had against this kind of operation, since a scripted, human-written attack doesn't leave the same trail of stated rationale behind it. Sysdig has made this same argument before, in an earlier writeup of an agentic threat actor pivoting from a CVE to an internal database in four moves; JadePuffer is the same category of actor operating at a larger scale.

The one place the evidence runs out is the Bitcoin address in the ransom note. 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy is the canonical example address used throughout Bitcoin developer documentation, the kind of illustrative string that saturates the training data behind code-generation models. It's also a live wallet, with 737 confirmed transactions and roughly 46 BTC received over its history, every deposit swept out immediately and a current balance of zero.

Sysdig lays out two readings without picking one: either the model hallucinated a plausible-looking address from its training data and the wallet belongs to a third party sweeping unsolicited deposits, or the operator configured the agent with a real, controlled wallet that happens to coincide with the documentation example. The researchers say they can't distinguish between the two without visibility into JadePuffer's system prompt or agent configuration.

Where Defenders Had a Window

1. The exposed Langflow validation endpoint: CVE-2025-3248 requires network access to Langflow's code-execution path. Organizations that don't expose that endpoint to the internet, and that patch to a fixed release, weren't reachable this way at all. This is the single highest-leverage window in the whole chain, because everything downstream depended on it.

2. Provider API keys sitting on a web-reachable host: The Langflow server held live API keys for four different LLM providers and cloud credentials for six more. Scoping credentials to the minimum resources required, favoring short-lived workload identities and preventing the internet-facing Langflow process from accessing unrelated cloud and provider credentials would have reduced the blast radius.

3. The default MinIO credentials: minioadmin:minioadmin is the out-of-the-box credential pair, and it worked. MinIO instances left on default credentials, whether internal-only or not, are a known, checkable gap.

4. The Nacos backdoor account creation: A new admin-role account appearing in a Nacos user table, especially one created and recreated twice within the same minute, is a loud, specific event. Database activity monitoring on Nacos's backing store would have surfaced this before the agent moved to encryption. Rotating Nacos's default token.secret.key, which has been publicly known since 2020, would have blocked the JWT-forgery path entirely.

5. The C2 beacon: The crontab entry calling out to attacker infrastructure every 30 minutes is unusual enough to catch with basic scheduled-task monitoring. Egress controls could have blocked the observed beacon to attacker infrastructure and any attempted connection to the purported staging host.

Takeaway for Defenders

JadePuffer didn’t require a new exploit or an advanced ransomware binary. It reached the environment through a known Langflow vulnerability, used default MinIO credentials, abused old Nacos authentication weaknesses and operated with a previously acquired database login.

The agent did more than make the work easier for the attacker. By interpreting results and correcting failures in seconds, it compressed the time between initial access and destructive action, leaving defenders fewer opportunities to detect one stage and intervene before the next began. A human operator could perform the same techniques, but not with the same combination of speed, persistence and continuous adaptation across hundreds of payloads.

That shifts the risk around neglected infrastructure. Old vulnerabilities and default credentials have always been exploitable, but an agent can test more paths, preserve context across them and move immediately when one succeeds. The marginal cost of exploring another credential, endpoint or historical weakness falls, especially when attackers are using stolen model access or compromised compute.

AI-orchestration systems therefore deserve the same treatment as other high-value application infrastructure. A Langflow deployment, an agent application built with LangGraph or a similar orchestration service may have access to provider APIs, cloud services, databases and internal tools. Exposing its execution surface while allowing the process broad access to long-lived secrets turns one application flaw into a path across the environment.

The defensive lesson is less exotic than the attack. Patch internet-facing systems. Replace defaults. Limit what application workloads can reach. Watch direct changes to authentication stores and restrict outbound traffic.

Sources

#Attack Chain Breakdowns