18/07/2026

JadePuffer: Anatomy of an Agentic Ransomware Attack That Ran an LLM as Its Operator

JadePuffer: Anatomy of an Agentic Ransomware Attack That Ran an LLM as Its Operator

A threat actor chained a Langflow RCE into a fully LLM-driven intrusion — recon, credential theft, lateral movement, and database encryption — with the model writing and self-correcting the payloads in real time. Here's the technical breakdown, mapped to the tools, CVEs, and techniques involved.

Cloud security firm Sysdig documented an intrusion that should worry anyone running exposed AI infrastructure. A threat actor tracked as JadePuffer compromised an internet-facing Langflow instance and used a large language model as the actual operator of the attack — not just a code-generation helper on the side, but the component parsing target state, deciding next actions, and rewriting payloads when they failed.

This is the shift the industry has been warning about: the barrier to a multi-stage intrusion is no longer a capable human. It's a capable model plus some neglected infrastructure. Let's walk the whole kill chain.

Initial access: CVE-2025-3248, unauthenticated RCE in Langflow

Langflow is a Python-based, LLM-agnostic open-source framework for building agent workflows. The entry point was CVE-2025-3248 (CVSS 9.8), a critical missing-authentication vulnerability disclosed in April 2025 and added to the CISA Known Exploited Vulnerabilities catalog shortly after.

The root cause is a classic code-injection anti-pattern. The /api/v1/validate/code endpoint passed user-supplied code straight into Python's built-in exec() with no authentication and no sandbox. The subtlety is when execution happens: when exec() evaluates a function definition, Python immediately runs expressions placed in default arguments and decorators as the AST is processed. So a payload never needs the function to be called — it detonates at definition time.

A minimal proof-of-concept looks like this:

POST /api/v1/validate/code HTTP/1.1
Host: victim:7860
Content-Type: application/json
 
{"code": "def x(a=exec('import os; os.system(\"id > /tmp/pwn\")')):\n    pass"}

The default-argument expression executes the instant the server validates the snippet — no auth token, no user interaction. Public exploits for this exist on Exploit-DB, and the same bug was previously used to drop the Flodrix botnet. The fix landed in Langflow 1.3.0, which requires authentication on that endpoint.

Phase 1: LLM-driven reconnaissance and credential harvesting

After landing code execution on the Langflow host, JadePuffer handed the wheel to the LLM. What's notable is that the model didn't just fire a static script — Sysdig observed it adapting in real time, parsing different file formats and adjusting its extraction logic on the fly. The recon and looting phase covered:

  • Secret sweeping across the filesystem — API keys, cloud credentials, cryptocurrency wallets, configuration files, and database credentials.
  • Postgres database dump of Langflow's own backing store to harvest secrets held inside it.
  • Internal network mapping — scanning the reachable address space and enumerating named services.
  • Object-storage targeting — probing for MinIO endpoints as a further credential-extraction surface.
  • Persistence via a cron job on the Langflow server, giving durable re-entry independent of the original exploit.

In ATT&CK terms this maps cleanly to Credential Access (T1552 — unsecured credentials), Discovery (T1046 — network service scanning), and Persistence (T1053.003 — scheduled task/cron). The novelty isn't the techniques; it's that an LLM sequenced and adapted them autonomously.

Phase 2: Lateral movement to a production database and Nacos

Using harvested credentials, the LLM pivoted to a production server running a MySQL database and an Alibaba Nacos (Naming and Configuration Service) platform — the configuration backbone of many microservice architectures, and a high-value target because owning the config store means owning the services that read from it.

The model connected using a payload carrying root MySQL credentials, then went after Nacos through several vectors simultaneously:

  • Auth-bypass exploitation via CVE-2021-29441. Nacos versions before 1.4.1 ship an AuthFilter with a User-Agent allowlist backdoor: when isEnableUserAgentAuthWhite() is true (the default), any request carrying the Nacos-Server User-Agent header skips authentication entirely. Trivially spoofable. See the NVD entry.
  • JWT forgery with the default signing key. Nacos's default JWT signing secret has been publicly documented since 2020 and ships unchanged in countless deployments. With it, forging a valid admin token is a one-liner — no bypass even required.
  • Direct backdoor-admin injection. With root database access already in hand, the attacker injected a rogue administrator account straight into the Nacos backing database, bypassing the application layer altogether.

Throughout, the LLM tuned its payloads to pass Nacos login verification, checked for MySQL User Defined Functions (UDFs) — a known path to OS command execution — and emitted a "completion marker" once it judged pre-encryption objectives were met.

The encryption stage: deliberately unrecoverable

The impact phase was clinical. The agent encrypted 1,342 Nacos service configuration items and wrote an extortion table into the database containing the ransom demand, a payment address, and a contact email.

The critical detail for incident responders: the encryption key was randomly generated and never persisted or transmitted. There is no key on disk, no key in transit to a C2 to intercept, no key-escrow mistake to exploit. From a recovery standpoint that's effectively data destruction wearing a ransom note — victims can pay and still get nothing back, because the key never existed anywhere retrievable.

Sysdig's captured payloads show the model escalating from row-level deletion to dropping entire schemas, narrating its own targeting rationale in natural-language comments alongside the code. Those comments — plus the way the payloads corrected failures and diagnosed errors mid-run — are the fingerprint of LLM-generated tradecraft.

Why this is genuinely different, not just hype

The tell that this wasn't a canned script: Sysdig notes the LLM "parsed free-text context presented by the target and took an action that only makes sense if that text was read and understood, rather than pattern-matched by a scanner." And this recurred across sessions weeks apart. A scanner matches signatures; this thing read the room.

Strip away the buzzwords and the strategic point is simple. Every individual technique here — an exec() injection, a User-Agent auth bypass, a default JWT key, a UDF-to-RCE pivot — is old, documented, and patchable. The AI contributed no novel exploit. What it contributed was orchestration and adaptation at near-zero cost: stitching known techniques into a coherent, self-correcting campaign against neglected infrastructure without a skilled human in the loop.

Detection and hardening

Nothing here is exotic to defend against, which is the point — the victims lost on hygiene, not on some unstoppable AI. Priorities:

Patch and inventory the actual entry points. Upgrade Langflow to ≥ 1.3.0 and Nacos to ≥ 1.4.1. Then hunt for what you didn't know was exposed — internet-facing AI builders, config stores, and DB admin panels are the first surfaces to fall.

Kill the defaults. Rotate the Nacos JWT signing key immediately — the default is public. Disable isEnableUserAgentAuthWhite. Change every default credential on config and service-registry platforms.

Get AI infrastructure off the public internet. Langflow and similar agent-builder frameworks were never meant to be exposed. Put them behind authentication, a VPN, or an identity-aware proxy. Treat them as sensitive application servers, because arbitrary code execution is their native capability.

Least privilege for the AI host. The Langflow box held reachable secrets, a dumpable Postgres, network line-of-sight to production, and MinIO credentials. Segment it. Scope its service account. Don't let a single agent host see your whole environment.

Instrument for runtime behavior, not just signatures. Cron jobs appearing on an app server, a Langflow process spawning shells or scanning internal ranges, MySQL loading a UDF, mass writes to Nacos config items — these are high-fidelity behavioral signals. Runtime detection (eBPF-based tooling like Falco/Sysdig, EDR) catches the actions even when the payloads are novel LLM output that no signature will match.

Hunt for the LLM fingerprint. Payloads with natural-language commentary, self-diagnosing retries, and adaptive parameter tuning across attempts are increasingly the signature of agentic tradecraft. Log and review payload bodies where you can.

The takeaway

JadePuffer is a preview, not an anomaly. Sysdig's guidance is blunt: expect the volume and breadth of these campaigns to rise as agentic tooling matures, and treat exposed application servers, unhardened configuration stores, and internet-facing database admin accounts as the first things that will be attacked.

The uncomfortable reframe for defenders: attackers no longer need a skilled operator for a multi-stage intrusion — they need a model and your unpatched edge. The economics of who can run a competent campaign just changed. Your patch cadence and your attack-surface discipline are now competing against automation that never sleeps and costs almost nothing to run.


Sources: Agentic AI Used to Conduct Ransomware Attack via Langflow — SecurityWeek (Ionut Arghire), reporting on Sysdig's JadePuffer research. Technical details: CVE-2025-3248 and CVE-2021-29441 (NVD).

JadePuffer: Anatomy of an Agentic Ransomware Attack That Ran an LLM as Its Operator

JadePuffer: Anatomy of an Agentic Ransomware Attack That Ran an LLM as Its Operator A threat actor chained a Langflow RCE into a fully LL...