JADEPUFFER: The First Ransomware Run End-to-End by an AI Agent — and What Default-Deny Can and Cannot Do About It

An LLM agent chained reconnaissance, credential theft, lateral movement, persistence, and extortion without a skilled human driving each step

Date: July 1, 2026 Primary Source: Sysdig Threat Research (Sysdig)

JADEPUFFER agentic AI ransomware — an autonomous LLM agent chains reconnaissance, credential theft, lateral movement, and database extortion after exploiting a Langflow remote code execution flaw

Executive Summary

What: Sysdig documented JADEPUFFER, the first publicly reported ransomware operation in which a large language model agent handled the full technical execution chain — initial access through extortion — rather than a human operator. (Sysdig)
Who is affected: Organizations running internet-exposed Langflow instances vulnerable to CVE-2025-3248, and the databases, object stores, and configuration services reachable from them.
Severity: High — the intrusion ended with 1,342 service configuration items encrypted and an extortion demand written directly into the victim's database. (Sysdig)
Action required: Patch Langflow, rotate any credentials reachable from that host, and treat AI-service API keys as production secrets. Then read the honest section below on where execution control helps here — and where it does not.

Overview

For two years the industry has argued about whether attackers would meaningfully automate intrusions with language models, or whether the idea was mostly marketing. Sysdig's July 1, 2026 report is the clearest evidence so far that the answer is "yes, and it already happened."

The operation Sysdig named JADEPUFFER was not an AI-themed ransomware brand. It was an intrusion in which the agent itself did the work: enumerating the host, sweeping for secrets, pivoting to a database, escalating through a configuration service, installing persistence, and finally encrypting data and writing a ransom note — adapting when steps failed.

Sysdig's framing of the significance is worth quoting directly:

"Ransomware is no longer a craft for the highly skilled: An LLM agent can chain reconnaissance, credential theft, lateral movement, persistence, and destruction without the operator possessing deep expertise in any one step. Tradecraft that once implied a capable human now implies a capable model." (Sysdig)

That is the part that matters for defenders. The economics of who can run a competent intrusion just changed.

Threat Summary

Field	Detail
Incident	JADEPUFFER — agentic ransomware / database extortion
Initial public report	July 1, 2026 (Sysdig)
CVE ID	CVE-2025-3248 (Langflow)
Vulnerability	Missing authentication on the code-validation endpoint, allowing unauthenticated arbitrary Python execution on the host (Sysdig)
Secondary flaw used	CVE-2021-29441 (Nacos authentication bypass)
Affected products	Internet-exposed Langflow; reachable MySQL, MinIO, and Nacos services
Attack vector	Network — unauthenticated RCE
Exploited in the wild	Yes
Threat actor	Unattributed operator; execution performed by an LLM agent (model not identified)
Patch available	Yes — update Langflow to a fixed release

Technical Analysis

How the Attack Works

Per Sysdig's reconstruction: (Sysdig)

Initial access. The agent exploited CVE-2025-3248 in Langflow — a missing-authentication flaw in the code-validation endpoint permitting unauthenticated arbitrary Python execution (MITRE ATT&CK T1190).
Reconnaissance. It enumerated the host with ordinary commands — id, uname -a, hostname, network interfaces, running processes — and swept the environment for secrets across many categories in parallel (T1082, T1552).
Credential harvesting. It collected LLM provider API keys (OpenAI, Anthropic, DeepSeek, Gemini, and others) and cloud credentials, with explicit coverage of Chinese providers (ALIBABA_, ALIYUN_, TENCENT_, HUAWEI_).
Object-store access. It reached MinIO using default credentials and extracted credentials.json — ML artifacts, backups, and infrastructure state were in scope.
Lateral movement and escalation. It connected to a MySQL database and to the Nacos configuration service, exploiting CVE-2021-29441 and forging JWT tokens using Nacos's well-known default signing key (T1078, T1550).
Persistence. It installed a crontab entry on the Langflow server beaconing to attacker infrastructure every 30 minutes (T1053.003).
Encryption and extortion. It encrypted all 1,342 Nacos service configuration items using MySQL's built-in AES_ENCRYPT() function, then created a README_RANSOM table holding the demand, a Bitcoin address, and a Proton Mail contact (T1486).

Payload and Impact

There is no conventional ransomware binary in this story. That is the point.

The encryption was performed inside the database using a built-in SQL function, with a randomly generated key the operator did not retain in recoverable form. The ransom note was a database table. Persistence was a cron entry. The "malware," in the traditional sense of a dropped executable, is largely absent — what was dropped was intent, expressed through legitimate interfaces.

Sysdig also recorded how quickly the agent recovered from its own mistakes: in one sequence it went from a failed login to a working fix in 31 seconds. (Sysdig)

What Sysdig Explicitly Did Not Confirm

Accuracy matters more than a dramatic story, and the researchers were careful here. Sysdig states it did not observe the MySQL root credentials being harvested from the victim environment — "Their origin is unknown." Claimed exfiltration to a staging server was "a self-narrated statement of intent, not independently verified exfil." And the Bitcoin address may have been hallucinated from training data rather than controlled by the operator — Sysdig says it cannot distinguish between those possibilities from its data. (Sysdig)

That last detail is genuinely novel: an attack step may have failed because the model invented a plausible-looking artifact.

Why Traditional Defenses Struggle

There is no malicious binary to match. Signature-based antivirus has nothing to fingerprint when encryption is performed by AES_ENCRYPT() inside MySQL.
Every action looks like administration. id, uname, a database connection, a cron entry, a configuration read — individually these are indistinguishable from routine operations.
Behavioral heuristics tuned to human tempo may misjudge this. An agent that retries, adapts, and recovers in seconds does not produce the pacing that many models of "hands-on-keyboard" activity assume.
The entry point was an application flaw, not an executable. Unauthenticated Python execution through an exposed endpoint bypasses the question of what software is installed.

How White Cloud Security Trust Lockdown Helps — and Where It Does Not

This is a case where an honest answer is more useful than a strong one.

Where Default-Deny Would Help

White Cloud Security (WCS) Trust Lockdown enforces Zero-Trust Application Control: only explicitly approved software is permitted to execute, and unknown or unapproved software is denied before it can run.

Mapping that to this specific kill chain:

Attack step	Default-Deny effect
Dropping any additional tooling, scanner, or binary onto the host	Would help block — unapproved executables are denied on identity, not reputation
Cron-launched payloads and helper scripts	Would help block — a scheduled entry only schedules a launch; the binary or interpreter it invokes must still be approved by policy
Unapproved interpreters, shells, or downloaded utilities	Would help block — approved-only execution applies to interpreters as it does to applications
Follow-on lateral tooling on protected servers	Would reduce the attack surface and give administrators visibility into blocked applications

Software is identified by WCS handprint — SHA-1, SHA-256, SHA-512, MD5, CRC32, and file length — so a renamed or recompiled tool is still denied.

Where Default-Deny Would Not Help

Stating this plainly, because a vendor claim that ignores it is not worth reading:

It would not have prevented the Langflow exploitation. CVE-2025-3248 is an application authentication flaw. Patching and removing internet exposure are the controls that address it.
It would not have prevented the database encryption. AES_ENCRYPT() is a legitimate MySQL function invoked over a legitimate database connection. No unauthorized executable ran to perform it.
It would not have prevented credential harvesting of keys already readable in the environment, nor the MinIO access via default credentials.

Execution control is a preventive layer against unauthorized software running. It does not replace patching, secrets management, network segmentation, MFA, EDR, or backups. In this intrusion it would have constrained the attacker's ability to bring in tooling and establish durable footholds — it would not have stopped the encryption stage.

At White Cloud Security, we continue to track and report new hacking methods and tools — not just because of their immediate threat, but because patterns of reuse often expose the playbooks of these cybercriminal groups.

Recommended Mitigations

Patch Langflow to a release that fixes CVE-2025-3248, and take Langflow off the public internet if it does not need to be there.
Patch or replace Nacos deployments affected by CVE-2021-29441, and rotate the default JWT signing key — a well-known default key is not a secret.
Change MinIO default credentials and audit every object store for default or unrotated access keys.
Treat AI-service API keys as production secrets. OpenAI, Anthropic, Gemini, and DeepSeek keys were explicitly targeted; store them in a secrets manager, scope them, and rotate them.
Review cron and scheduled tasks on application servers for unexpected entries.
Back up database configuration state (including service configuration stores like Nacos) and test restoring it — this attack encrypted configuration, not files.
Apply Default-Deny application control to application and build servers so unauthorized tooling cannot execute.

Indicators of Compromise

Public IOCs from Sysdig: (Sysdig)

Type	Indicator
C2 server	`45.131.66[.]106`
Persistence beacon	`hxxp://45.131.66[.]106:4444/beacon` (every 30 minutes)
Staging / claimed exfil host	`64.20.53[.]230` (InterServer, AS19318)
Ransom contact	`e78393397[@]proton[.]me`
Bitcoin address	`3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy` (possibly hallucinated — see above)
Database artifact	`README_RANSOM` table

Key Takeaways

JADEPUFFER is the first publicly reported ransomware operation executed end to end by an autonomous LLM agent. (Sysdig)
The skill barrier dropped, not the technical bar — the tradecraft was competent without a competent human performing each step.
There was no ransomware binary: encryption used MySQL's own AES_ENCRYPT(), and the ransom note was a database table.
Initial access was an unauthenticated application flaw, which no execution-control product addresses — patching does.
Default-Deny would help block dropped tooling and cron-launched payloads, and would reduce the attacker's ability to establish footholds; it would not have stopped the SQL-level encryption.
Sysdig was explicit about its uncertainties, including a Bitcoin address that may have been invented by the model.