Langflow flaw hits CISA KEV after rapid exploitation

CISA added CVE-2026-33017 to the Known Exploited Vulnerabilities catalog on March 25, after attackers started exploiting a Langflow remote code execution bug within about 20 hours of disclosure. If you run Langflow for agent orchestration, internal demos, or public workflow endpoints, this is an urgent patching event because the vulnerable path sits directly on flow execution and can expose the secrets those workflows use.

Exploit path

The vulnerable endpoint was POST /api/v1/build_public_tmp/{flow_id}/flow, documented in Langflow’s GHSA-vwmf-pq79-vjvx advisory. The endpoint was intentionally unauthenticated for public flows, but it also accepted attacker-controlled data and passed it into the flow-building path.

From there, malicious Python embedded in node definitions could reach exec() without sandboxing. Langflow listed three practical conditions for exploitation: the target had at least one public flow, the attacker knew the public flow UUID, and the request needed no real authentication beyond an arbitrary client_id cookie.

This is why the bug matters beyond a normal app-layer RCE. Langflow instances often sit near model API keys, vector stores, databases, tool credentials, and agent state. If you build with agent frameworks, or expose public agent workflows for testing and sharing, the blast radius extends into every connected system.

Affected versions and patched line

Langflow marked versions <= 1.8.2 as affected and >= 1.9.0 as patched in the advisory. The NVD entry for CVE-2026-33017 now reflects the same vulnerable range and tags the issue as Critical, with CVSS v4 at 9.3 and CVSS v3.1 at 9.8.

The version detail matters because early coverage referred to 1.8.1 and earlier. Current authoritative records point to <= 1.8.2 as vulnerable, so inventory checks should use that range.

Fix details

The core remediation is straightforward. In Langflow commit 73b6612, the build_public_tmp code stopped passing requester-supplied data into start_flow_build(...) and forced data=None, so public flow builds load only from the server-side database definition.

That change closes the exact trust boundary that failed. Public execution endpoints can exist, but the client cannot be allowed to replace the flow definition that the server is about to compile and run.

Exploitation timeline

The speed of exploitation is the operational story. Sysdig observed the first exploitation attempts within 20 hours of disclosure, before a public proof of concept was available, in its CVE-2026-33017 incident analysis.

Sysdig also reported a second wave during hours 21 through 24 using custom Python scripts with the python-requests/2.32.3 user agent. The activity included credential and environment harvesting, with theft risk extending to connected databases and other downstream services.

CISA’s KEV addition turned that fast-moving exploitation into a federal remediation deadline. Agencies covered by BOD 22-01 have until April 8, 2026 to apply mitigations, follow cloud-service guidance, or discontinue use.

Operational impact for AI teams

Langflow is not a passive UI. It is an execution surface for AI workflows. A compromise can hijack prompts, tool calls, stored credentials, and the data paths feeding your agents.

For teams building stateful AI agents, this is the same core lesson seen across agent security: execution layers and memory layers become high-value targets because they aggregate secrets and business logic. Public demo endpoints are especially exposed.

The issue also reinforces why code execution in agent systems needs hard isolation. If your architecture lets workflow definitions, tools, or generated code reach Python execution, use sandboxing and process isolation by default. Work on sandboxed agent execution is becoming relevant for exactly this reason.

Status snapshot

Item	Value
CVE	CVE-2026-33017
Product	Langflow
Vulnerability	Unauthenticated remote code execution via public flow build endpoint
Affected versions	<= 1.8.2
Patched versions	>= 1.9.0
KEV added	March 25, 2026
Federal due date	April 8, 2026
CVSS v4	9.3 Critical
CVSS v3.1	9.8 Critical

If you operate Langflow anywhere in production, staging, or shared internal environments, patch to 1.9.0 or later immediately, remove or restrict public flows until the upgrade is complete, and rotate every credential that may have been reachable from the instance, especially API keys, .env secrets, database credentials, and tokens tied to your agent memory or retrieval stack.