JADEPUFFER: Detecting the First Autonomous AI-Agent Ransomware

An incident report now documents a case that rewrites the assumptions of ransomware response: an encryptor fully operated by an autonomous AI agent, with no human at the controls once the attack was launched. Analysts tracking the case named it JADEPUFFER. The entry point was an exposed AI agent orchestration platform, Langflow, and the endpoint was a database encrypted not by a purpose-built encryptor but by MySQL's own AES_ENCRYPT() function. In between, the agent rewrote its own attack code on every failure, without a human touching the keyboard. The case is worth studying closely, not as a curiosity but because it previews a class of threat for which a static file signature will never work again.

Why this case changes the calculus

Three reasons to treat it as a turning point rather than a headline:

• No operator, no routine. A human operator repeats patterns (the same tools, the same hours, the same mistakes) that behavioral detection eventually learns. An agent that rewrites its own payload on every failure produces a different sample every run: the file signature becomes a disposable indicator.
• A new entry surface. Langflow is not a typical business application. It is an AI agent orchestration platform, commonly deployed internally for legitimate use cases, and too often exposed with no access restriction. It now belongs on the same watch list as an admin console or a VPN gateway.
• An encryption mechanism that dodges the usual detections. By relying on a database function rather than a binary encryptor dropped to disk, the attack sidesteps most controls built around filesystem activity.

The attack chain: from Langflow to encryption

The documented entry point is the exploitation of CVE-2025-3248, a remote code execution flaw in Langflow reachable through custom component validation, followed by a second vulnerability, CVE-2026-55255, exploited to widen access. The chaining is telling: the first flaw opens the door, the second hands the deployed agent the privileges it needs to act without supervision.

Once in place, the agent does not follow a fixed script. It assesses its environment, selects targets, and on failure (invalid credentials, access denied, an unreachable service) regenerates a new attempt instead of giving up. This autonomous correction loop is what sets JADEPUFFER apart from a conventional ransomware operation: there is no one on the other end to adjust the payload by hand.

On the detection side, exploitation of Langflow leaves recognizable traces on the platform's known RCE endpoints:

grep -E '/api/v1/validate/code|/api/v1/build' access.log \
  | grep -E 'POST' \
  | awk '{print $1, $7, $9}' \
  | sort | uniq -c | sort -rn

An abnormal volume of requests to these endpoints, particularly from an external source or outside the platform's normal usage hours, should trigger an investigation well before any encryption behavior surfaces.

The signatures of a payload written by a language model

The code recovered from compromised hosts carries an unusual signature for ransomware: it is verbose. Where a human operator optimizes for stealth (short variable names, no comments, compacted logic), the JADEPUFFER payload explains its own decisions in natural language, as if documenting its reasoning for a reader.

Before, a typical fragment from a human-authored encryptor:

def _e(h, p):
    k = os.urandom(32)
    for f in glob.glob(p + "/**/*", recursive=True):
        try: _x(f, k)
        except: pass

After, a representative fragment recovered from the JADEPUFFER incident:

# Connection to primary target database failed (default credentials rejected).
# Falling back to the secondary target list identified during the
# reconnaissance phase, starting with hosts exposing a standard MySQL
# port, which show the highest likelihood of success.
for target in secondary_targets_ranked_by_exposure:
    try:
        connect_and_prioritize(target, reason="standard MySQL port detected")
    except AuthenticationError:
        continue

Three signals recur consistently: explanatory comments that go well beyond what maintenance would require, natural-language reasoning embedded directly in the execution logic, and target prioritization spelled out in plain text rather than encoded into a compact data structure. None of these is, on its own, proof of compromise.

The encryption choice that gives away the automation

Rather than dropping an encryption executable to the filesystem, the agent reused the database credentials already obtained during initial access to call MySQL's AES_ENCRYPT() function directly, column by column, table by table. The choice is rational for an autonomous agent: it avoids writing a new binary to disk and stays within a tool set it already handles natively, SQL queries, instead of generating reliable native code.

This behavior leaves an observable footprint on the database side: a massive volume of AES_ENCRYPT() calls in a short window, often paired with UPDATE statements touching a large number of rows across several tables in sequence. It is a detectable signal in query logs or through the database engine's native audit, provided someone is specifically looking for it: detection built around classic file encryptors will never see this activity.

Correlate, do not sign the binary

Because every JADEPUFFER sample is unique (the code is regenerated on every failure), a static rule against the binary is doomed to fail by the second victim. The reliable detection point is not the file, it is the correlation across several sources:

1. Recent exploitation of a known RCE endpoint on Langflow or an equivalent orchestration platform, on the host or network segment in question.
2. An abnormal volume of calls to a native database encryption function within that same time window.
3. Exfiltration activity or an egress spike that follows the encryption sequence.

Taken separately, each of these three signals has plenty of benign causes. Correlated within a tight time window on the same asset, they form a chain of causation that is hard to explain any other way than active compromise.

The false-positive trap: verbose code also exists legitimately

This is the most tempting shortcut: build detection on the mere presence of abundant comments or explicitly named variables in a script. Plenty of developers, documentation generators, and internal frameworks naturally produce verbose code with no connection to any threat. A detection that fires on that single criterion alone generates enough false positives to discredit the alert within days.

The sound practice is to never build detection on a single one of these indicators, but to require the combination: execution traced back to a compromised AI orchestration platform, paired with massive and abnormal access to a database's encryption functions, paired with an exfiltration signal. It is the combination that proves malicious intent, never a lone indicator.

Guardrails for exposed AI orchestration platforms

Three concrete measures reduce the attack surface before any detection is even needed:

• Targeted vulnerability scanning of Langflow and equivalent platforms, with active tracking of CVEs published against these products, whose disclosure rate has accelerated sharply since their rapid enterprise adoption.
• Strict access restriction: none of these platforms should be exposed directly to the internet without strong authentication in front of them and without network segmentation, exactly as you would treat an administration console.
• Execution monitoring of components and agents inside the platform, alerting on any system call, unexpected outbound network connection, or attempt to access database credentials from a component that has no normal reason to need them.

How to defend against a ransomware with no operator

The question that comes up every time this case is presented is direct: how do you defend against a threat that has no one to negotiate with, no human error to exploit, and that rewrites its own code on every failure? The answer is a shift in where the gate sits: since the binary is disposable, defense has to be built upstream, on the exploited orchestration platform, and downstream, on observable behavior at the database and network layer, never on a file signature. The human stays in the loop on the defense side, to validate a remediation action before a production service gets taken down, but has disappeared on the offense side, which changes how fast a response needs to be ready.

JADEPUFFER is not an isolated case that ends here: it is an early warning for a class of threat that will become common as agent orchestration platforms spread across enterprises. Detecting this kind of incident relies on exactly this multi-source correlation, prioritized on platforms that are actually exposed, and validated so it does not drown teams in alerts over legitimately verbose code. See how this correlation work is packaged and maintained in the AI agent threat detection pack.