An AI agent ran a complete ransomware attack autonomously. The entry point was already flagged critical.#

July 2, 2026

Sysdig's Threat Research Team has documented what they believe is the first ransomware attack executed from start to finish by an AI agent with no human in the loop. They call the operator JADEPUFFER.

The agent broke in, stole credentials, moved laterally, encrypted a production database, and left a ransom note. It ran more than 600 purposeful payloads. When it hit a failed login, it diagnosed the cause and corrected its own approach in 31 seconds. No human made a decision at any point in the chain.

The entry point was CVE-2025-3248, an unauthenticated remote code execution vulnerability in Langflow. Attestd has been returning risk_state: critical and actively_exploited: true for vulnerable Langflow versions since before this attack ran. The signal was there. An autonomous defender had everything it needed to block the first step.

This post is about what that signal looks like, what the attack did after it got past the entry point, and why JADEPUFFER is not an isolated incident.

The entry point: CVE-2025-3248#

Langflow is an open-source tool for building AI applications and agent workflows. CVE-2025-3248 is a missing-authentication flaw that allows anyone who can reach the server to run arbitrary Python code on it. No login required. The flaw was patched in Langflow 1.3.0 and added to CISA's Known Exploited Vulnerabilities list in May 2025.

JADEPUFFER exploited it against a server that had never been updated.

curl "https://api.attestd.io/v1/check?product=langflow&version=1.0.0" \
  -H "Authorization: Bearer $ATTESTD_API_KEY"

{
  "product": "langflow",
  "version": "1.0.0",
  "supported": true,
  "risk_state": "critical",
  "risk_factors": [
    "active_exploitation",
    "remote_code_execution",
    "no_authentication_required",
    "internet_exposed_service",
    "patch_available"
  ],
  "actively_exploited": true,
  "remote_exploitable": true,
  "authentication_required": false,
  "patch_available": true,
  "fixed_version": "1.3.0",
  "confidence": 0.5,
  "cve_ids": [
    "CVE-2025-3248",
    "CVE-2026-33017",
    "... (32 more)"
  ],
  "last_updated": "2026-07-02T11:49:07.169323Z",
  "supply_chain": {
    "compromised": false
  }
}

Five simultaneous risk factors. risk_state: critical. actively_exploited: true. authentication_required: false. The fixed version is in the response. An autonomous system querying this before running a Langflow dependency would have the complete picture in a single API call and a clear action: do not proceed, upgrade to 1.3.0.

A note on the confidence score of 0.5: Langflow has an unusually large and rapidly growing CVE set. The confidence reflects uncertainty in the completeness of the version range picture across all CVEs, not in the critical and exploitation signals themselves. Those are sourced from verified CISA KEV data and are not subject to the same uncertainty. The correct response to risk_state: critical and actively_exploited: true at confidence 0.5 is the same as at 0.95: do not proceed without explicit operator override.

What the agent did after it got in#

Once inside the Langflow server, JADEPUFFER moved fast and cleaned up after itself.

It swept the machine for secrets: API keys for OpenAI, Anthropic, DeepSeek, and Gemini, cloud credentials for AWS, Google, Azure, and Chinese providers including Alibaba and Tencent, cryptocurrency wallet keys, and database credentials.

It accessed a MinIO storage server using factory default credentials that had never been changed. It established a persistence mechanism, a scheduled task that beaconed to the attacker's server every 30 minutes.

Then it pivoted to its real target: a separate internet-facing server running MySQL and Alibaba's Nacos service registry. It logged into MySQL as root. Sysdig notes they could not determine where those root credentials came from.

curl "https://api.attestd.io/v1/check?product=mysql&version=8.0.30" \
  -H "Authorization: Bearer $ATTESTD_API_KEY"

{
  "product": "mysql",
  "version": "8.0.30",
  "supported": true,
  "risk_state": "elevated",
  "risk_factors": [
    "remote_code_execution",
    "patch_available"
  ],
  "actively_exploited": false,
  "remote_exploitable": true,
  "authentication_required": true,
  "patch_available": true,
  "fixed_version": null,
  "confidence": 0.75,
  "cve_ids": [
    "CVE-2022-21594",
    "... (137 more)"
  ],
  "last_updated": "2026-07-02T11:49:07.169323Z",
  "supply_chain": {
    "compromised": false
  }
}

MySQL at this version returns risk_state: elevated with known RCE exposure. The JADEPUFFER attack did not exploit a specific MySQL CVE in the way it exploited Langflow: it used root credentials that were either stolen from the Langflow environment or obtained through the Nacos compromise. The MySQL signal here is not "this version was targeted in this attack" but rather "this version has known RCE exposure and 137 CVEs," which is the ongoing risk state of any system that has not been patched.

From the MySQL database, the agent used a 2021 authentication bypass in Nacos and a default signing key that Nacos has shipped unchanged since 2020 to plant its own admin account. It then encrypted all 1,342 Nacos configuration entries, dropped the original tables, and left a ransom note demanding Bitcoin with a Proton Mail contact.

It generated a random encryption key, printed it to the screen once, and discarded it. There is no key to hand over. The victim cannot recover the data regardless of whether they pay.

It then deleted whole databases entirely.

How researchers knew an AI was driving#

The clearest indicator was the code itself. Every payload contained plain-English comments explaining the reasoning behind each step, the kind of running commentary a human attacker never writes but a language model produces by default. The agent also corrected its own mistakes without human intervention. A failed login attempt was diagnosed and corrected with a multi-step fix in 31 seconds.

Sysdig counted more than 600 separate, purposeful payloads across the operation.

This is not a script. Scripts do not diagnose their own failures and self-correct at machine speed. This is an agent reasoning about its own output and adapting in real time.

The machine speed argument, stated plainly#

JADEPUFFER is the argument for machine-speed security infrastructure made concrete.

The individual techniques JADEPUFFER used were not sophisticated. CVE-2025-3248 was patched over a year before this attack. The Nacos default signing key has been a known issue since 2020. The MinIO compromise used factory-default credentials. None of these required novel research or insider knowledge.

What JADEPUFFER demonstrated is that the skill floor for running a complete attack chain is collapsing. An agent can chain a year-old public vulnerability into a full ransomware operation, diagnose its own errors, move laterally, establish persistence, and encrypt a production database without a human making a single decision. The time from "found an exposed server" to "database encrypted" is whatever the agent needs to complete the chain, potentially hours.

A daily digest email, a weekly vulnerability report, a Jira ticket assigned to the platform team, none of these operate in the same time domain as JADEPUFFER. By the time a human reads a notification about an exposed Langflow instance, the agent has already encrypted the database.

Sysdig frames JADEPUFFER as a warning sign rather than a crisis. That framing is accurate today. It will not remain accurate as agent tooling matures.

The defense that matches JADEPUFFER's operating model is autonomous infrastructure that continuously evaluates its own security state and can act on that state without a human decision in the loop. Not a scanner you run before deployment. A persistent sensor that knows the risk state of every component in the stack and can flag or block action before the agent on the other side gets its first foothold.

CVE-2025-3248 returned risk_state: critical and actively_exploited: true before JADEPUFFER ran this attack. The signal was there. The question is whether the defender was consuming it.

This is distinct from the supply chain attacks in the detection ledger#

Every supply chain post in the Attestd detection ledger, Mastra, Fake Font, the chai brandjacking campaign, returned the same pattern: risk_state: none with supply_chain.compromised: true. No CVEs. Clean on vulnerability signals. Compromised at the package layer.

JADEPUFFER inverts that pattern. Langflow returns risk_state: critical with supply_chain.compromised: false. No supply chain compromise. The attack came through a CVE in the product itself.

Both patterns exist. Both require detection. A security layer that checks only CVEs passes supply chain attacks clean. A security layer that checks only supply chain signals passes CVE-based attacks clean. Attestd checks both in the same API call because attackers use both, sometimes in the same campaign.

Coverage#

Langflow is covered. MySQL is covered. Both responses above are live from the production API as of July 2, 2026. The entry point CVE-2025-3248 is in the Langflow response alongside CVE-2026-33017, documented in the previous post on Langflow exploitation.

The signal was there before JADEPUFFER ran. It still is.

API documentation: attestd.io/docs. Detection ledger: github.com/attestd-io/detection-ledger. Machine speed thesis: attestd.io/thesis.