Actively Exploited. This vulnerability has been added to CISA's [Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-33017) on March 25, 2026 with a remediation deadline of April 8, 2026. Federal agencies are required to apply mitigations per [BOD 22-01](https://www.cisa.gov/binding-operational-directive-22-01).
CVE-2026-33017 is an unauthenticated remote code execution (RCE) vulnerability in Langflow, a popular tool for building and deploying AI-powered agents and workflows. The POST /api/v1/build_public_tmp/{flow_id}/flow endpoint allows building public flows without authentication. When the optional data parameter is supplied, the endpoint uses attacker-controlled flow data (containing arbitrary Python code in node definitions) instead of stored flow data. This code is passed to exec() with zero sandboxing, resulting in unauthenticated remote code execution.
This vulnerability is distinct from CVE-2025-3248, which fixed /api/v1/validate/code by adding authentication. That earlier CVE was itself added to CISA's KEV catalog due to active exploitation.
Key difference: The build_public_tmp endpoint is *designed* to be unauthenticated (for public flows). The issue is that it incorrectly accepts attacker-supplied flow data containing arbitrary executable code via the data parameter. A simple authentication fix is insufficient — the endpoint must be restricted to only use stored flow data from the database.
| Aspect |
CVE-2025-3248 |
CVE-2026-33017 |
| Endpoint |
/api/v1/validate/code |
/api/v1/build_public_tmp/{id}/flow |
| Fix applied |
Added authentication |
Removed data parameter (v1.9.0) |
| Root cause |
Missing auth on code validation |
Unauth endpoint accepts attacker-controlled executable code |
| Execution via |
validate_code() → exec() |
create_class() → prepare_global_scope() → exec() |
Unauthenticated remote code execution in Langflow via the public flow build endpoint.
The root cause is a combination of CWE-94 (Code Injection), CWE-95 (Eval Injection), and CWE-306 (Missing Authentication for Critical Function). The vulnerable endpoint /api/v1/build_public_tmp/{flow_id}/flow is designed to be unauthenticated for building public flows. However, when the optional data parameter is supplied, the endpoint uses attacker-controlled flow data instead of stored database data. The attacker's flow data contains arbitrary Python code in node definitions, which flows through the graph builder:
start_flow_build(data=attacker_data) → generate_flow_events()
create_graph() → build_graph_from_data(payload=data)
Graph.from_payload() → node initialization → instantiate_class()
eval_custom_component_code(code) → create_class()
prepare_global_scope() → exec(compiled_code, exec_globals)
The exec() call has zero sandboxing — any Python code is executed with full server process privileges. Even simple assignment statements (e.g., _x = os.system("id")) are executed during graph building, before the flow even "runs."
| Requirement |
Detail |
| Public flow exists |
Target instance has at least one public flow (common for demos, chatbots, shared workflows) |
| Flow UUID known |
Discoverable via shared links/URLs |
| Authentication |
None required — only a client_id cookie (any arbitrary string) |
AUTO_LOGIN=true (the default): When auto-login is enabled, an attacker can meet *all* prerequisites without any credentials:
GET /api/v1/auto_login → obtain superuser token
POST /api/v1/flows/ → create a public flow
- Exploit via
build_public_tmp without any auth
| Product |
Affected Versions |
Fixed Version |
| Langflow (pip) |
≤ 1.8.2 |
1.9.0 |
Fix: The fix in version 1.9.0 removes the ability for the build_public_tmp endpoint to accept attacker-supplied flow data. Public flows now only execute their stored flow data from the database. Patch commit: [73b6612](https://github.com/langflow-ai/langflow/commit/73b6612e3ef25fdae0a752d75b0fabd47328d4f0).
| Impact Area |
Detail |
| Confidentiality |
High — Arbitrary file read, environment variable exfiltration (API keys, DB credentials, cloud tokens) |
| Integrity |
High — Arbitrary file write, command execution, flow/data manipulation |
| Availability |
High — Full server process control, denial of service |
| Attack Vector |
Network — remotely exploitable over the internet |
| Privileges Required |
None — completely unauthenticated |
| User Interaction |
None — no user action needed |
Full Server Compromise. Successful exploitation grants full server process privileges, enabling:
- Arbitrary command execution and reverse shell access
- Environment variable exfiltration (API keys, database credentials, cloud tokens)
- Access to all flows, messages, and stored credentials in the database
- Lateral movement within the network
- Persistent backdoor installation
Exploitation is trivially simple. A single unauthenticated HTTP POST request with a crafted data parameter containing a malicious node definition is sufficient.
Exploitation complexity is extremely low. No authentication, no special tools, and no user interaction required. The PoC achieves 100% reproducibility (confirmed 6/6 runs across two test sets). Active exploitation in the wild has been confirmed by CISA and [Sysdig](https://www.sysdig.com/blog/cve-2026-33017-how-attackers-compromised-langflow-ai-pipelines-in-20-hours).
- Attacker identifies a Langflow instance with a public flow (or creates one via
AUTO_LOGIN).
- Attacker sends a POST request to
/api/v1/build_public_tmp/{flow_id}/flow with a data parameter containing a node whose code field holds arbitrary Python.
- Langflow's graph builder parses the attacker's node definitions and calls
prepare_global_scope() → exec() on the code.
- Attacker's Python code executes with full server process privileges — during graph building, before the flow even "runs."
- Attacker achieves arbitrary command execution, credential exfiltration, or reverse shell.
CISA BOD 22-01 Deadline: April 8, 2026. Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable.
| Product |
Fixed Version |
| Langflow |
1.9.0 and later |
- Upgrade immediately to Langflow 1.9.0 or later.
- Disable AUTO_LOGIN — set
AUTO_LOGIN=false if not already done. The default AUTO_LOGIN=true setting allows unauthenticated users to create public flows, making exploitation trivial even without pre-existing public flows.
- Restrict network access — if patching is not immediately possible, restrict access to the Langflow instance to trusted networks only. Do not expose Langflow directly to the internet.
- Review server logs — check for suspicious POST requests to
/api/v1/build_public_tmp/ endpoints, especially those with a data parameter containing code fields.
- Rotate credentials — if exploitation is suspected, rotate all API keys, database credentials, cloud tokens, and other secrets accessible to the Langflow server process.
- Monitor CISA KEV Catalog for updated guidance.