Langflow's public build endpoint: unauthenticated RCE weaponised in 20 hours

What is this?

Langflow is a widely deployed open-source visual framework for building LLM agents and Retrieval-Augmented Generation (RAG) pipelines. CVE-2026-33017, disclosed on March 17, 2026, is an unauthenticated remote code execution flaw in its public flow-build endpoint. NVD scores it 9.8 (CVSS 3.1); the GitHub CNA record rates it 9.3 (CVSS 4.0). It is rare for any of those scores to be the headline. Here, the headline is the clock: Sysdig’s Threat Research Team observed exploitation in the wild within 20 hours of the advisory, before any public proof-of-concept existed. Attackers read the advisory, wrote the exploit, and started scanning the internet.

This is a defensive write-up of an already-disclosed, already-patched vulnerability. No payload is reproduced — the fix is public, the lesson is operational.

How it works

The flaw lives in a single endpoint that was reachable without authentication:

POST /api/v1/build_public_tmp/{flow_id}/flow

In versions through 1.8.1, this endpoint accepts an optional data parameter. When that parameter is supplied, the endpoint builds the flow from attacker-controlled flow data instead of the stored flow definition from the database. A Langflow “flow” is a graph of nodes, and node definitions can carry Python code. That code path reaches exec() with no sandboxing — so attacker-supplied node code runs on the host as the Langflow process.

Request (unauthenticated)
  -> build_public_tmp endpoint
  -> optional `data` = attacker flow graph
  -> node definition contains Python
  -> exec()  [no sandbox]
  -> code runs on host

The fix in 1.9.0 removes the data parameter from the public build endpoint entirely, so the endpoint can no longer be handed an attacker-controlled graph. There is an important wrinkle: an interim 1.8.2 was reported as patched, but JFrog Security Research demonstrated that 1.8.2 remained exploitable and could not identify a corresponding patch in its commits. The practical consequence is that a version number alone was not a reliable signal of remediation.

Post-exploitation, threat researchers reported intrusions that pivoted straight to value: stealing cloud credentials (AWS keys) and deploying worker payloads on compromised hosts. The endpoint gives unauthenticated code execution; everything after that is ordinary post-exploitation against whatever the Langflow host can reach.

Why it matters

The first reason is the 20-hour weaponisation window. There was no PoC to copy. The advisory text was enough to reconstruct the bug, and the gap between “disclosure” and “internet-wide scanning” collapsed to under a day. Any patch SLA that assumes you have a week of quiet after a CVE drops is calibrated to a threat model that no longer holds for internet-facing AI tooling.

The second reason is where this software runs. Langflow is a builder — a developer convenience that frequently ends up exposed on a cloud VM with broad outbound access and ambient cloud credentials, precisely because it was “just” an internal prototyping tool. That is the worst possible host for an unauthenticated RCE. CISA added CVE-2026-33017 to its Known Exploited Vulnerabilities catalog on March 25, 2026, with a Federal Civilian Executive Branch remediation deadline of April 8 under Binding Operational Directive 22-01 — a signal that this was hitting real, exposed deployments, not just lab instances.

The third reason is exec() on user-controlled graph data is a pattern, not a one-off. Many LLM-orchestration and agent-builder frameworks evaluate user-supplied “flows”, “tools”, or “skills” that embed code. If your own stack turns a serialized agent definition into executed Python or shell, you may own the same bug under a different name. The Langflow node graph is just the most visible instance.

Defenses

1. Upgrade to 1.9.0 or later — and verify, do not trust the version string. Given the 1.8.2 bypass, confirm the data parameter is gone from build_public_tmp in your running build rather than assuming a labelled “fixed” release is fixed.

2. Take Langflow off the public internet. A flow-builder has no business listening on 0.0.0.0 with a routable IP. Bind to localhost, or place it behind a VPN / authenticated reverse proxy with a network ACL. Most exploited instances were simply reachable.

3. Re-baseline patch SLAs for internet-facing AI tooling. The 20-hour figure is the planning number now. Treat advisory publication — not PoC release — as the start of the exploitation clock, with an emergency out-of-cycle path for unauthenticated RCEs on exposed assets.

4. Strip ambient credentials and constrain egress. No standing AWS/cloud keys on the Langflow host; use scoped, short-lived IAM and default-deny outbound. This blunts the observed credential-theft and worker-deployment post-exploitation even if execution occurs.

5. Eliminate exec()/eval() over user-controlled definitions in your own builders. If agent/flow/skill definitions can carry code, run them in a sandbox (separate process, seccomp, container with no host mounts, no network) — never inline in the orchestrator process.

6. Hunt for the indicators. Alert on requests to build_public_tmp, on anomalous child processes spawned by the Langflow process, and on unexpected outbound connections (credential endpoints, unknown C2/worker brokers). Inventory your exposure with an external scan (Shodan/Censys) before an attacker does.

Status

Item	Reference	Date	Notes
CVE-2026-33017 disclosed	NVD / GitHub CNA	2026-03-17	Unauthenticated RCE, CVSS 3.1 9.8 / CVSS 4.0 9.3
In-the-wild exploitation	Sysdig TRT	~2026-03-18	Within 20 hours of advisory, no public PoC
Added to CISA KEV	CISA / Help Net Security	2026-03-25	FCEB remediation deadline 2026-04-08 (BOD 22-01)
Patch	Langflow 1.9.0	2026	Removes data parameter from build_public_tmp
1.8.2 still exploitable	JFrog Security Research	2026	”Fixed” interim release demonstrated bypassable

The bug is patched. The reusable lesson is not about Langflow at all: an unauthenticated builder that runs user-supplied code, left exposed to the internet, will be exploited from the advisory text faster than most teams can schedule a patch window. Find your exposed AI tooling and close it before the next advisory tests that assumption for you.