CVE-2026-33017

What it actually does

CVE-2026-33017 is an unauthenticated remote code execution vulnerability in Langflow versions before 1.9.0. The public flow build endpoint, POST /api/v1/build_public_tmp/{flow_id}/flow, is intentionally reachable without authentication for public flows, but it incorrectly accepts an optional attacker-supplied data parameter. When that parameter is provided, Langflow uses the submitted flow definition instead of the stored flow definition and processes Python code embedded in node definitions with exec() without sandboxing. An attacker with network access to the endpoint can therefore execute arbitrary Python code in the context of the Langflow application process, potentially leading to command execution on the host, credential theft, data access, persistence, lateral movement, and service disruption.

Why it matters to the business

Successful exploitation can give an external attacker control over systems running vulnerable Langflow instances without needing credentials. Because Langflow commonly connects to AI services, APIs, databases, workflow secrets, and internal automation components, compromise may expose sensitive prompts, API keys, model provider credentials, business data, and downstream integrations. The vulnerability is listed in CISA KEV with a remediation due date of 2026-04-08, has a very high EPSS score of 0.99836, and is reported as actively exploited in the wild, including activity associated with the Interlock ransomware campaign; organizations should treat internet-exposed instances as high-priority incident-response candidates, not merely patching tasks.

How an attack unfolds

An attacker first identifies a reachable Langflow service and probes for the unauthenticated public flow build endpoint. They then send a crafted POST request to /api/v1/build_public_tmp/{flow_id}/flow containing the optional data parameter with a malicious flow definition. Instead of loading the legitimate public flow from storage, the vulnerable server accepts the attacker-controlled flow data. During the build process, Python code embedded in the malicious node definitions is passed to exec() without authentication, authorization, or sandboxing. The code runs with the privileges of the Langflow process, allowing the attacker to execute operating system commands, read local files and environment variables, retrieve API tokens, download additional payloads, create reverse shells, or stage ransomware-related tooling. After initial execution, attackers may enumerate secrets and connected services, establish persistence, pivot to other systems reachable from the Langflow host, and erase or minimize logs.

How to fix it

Upgrade Langflow to version 1.9.0 or later, which fixes the vulnerable behavior. If immediate upgrade is not possible, restrict access to Langflow at the network layer, especially the /api/v1/build_public_tmp/{flow_id}/flow endpoint; place Langflow behind authentication-aware reverse proxies or VPN access; disable public flow building where feasible; block unauthenticated access from the internet; and monitor or temporarily disable public flow functionality until patched. Rotate secrets available to the Langflow process, including API keys, model provider tokens, database credentials, integration credentials, and environment-variable secrets, if the instance was exposed before patching. Because exploitation is active in the wild and the vulnerability is in KEV, patching should be handled as an emergency change for exposed systems.

How to confirm the fix worked

Confirm the installed Langflow version is 1.9.0 or later. Review package metadata, container image tags, deployment manifests, and runtime startup logs to ensure the running service, not only the source repository, has been updated. Attempt a safe negative validation by sending an unauthenticated request to POST /api/v1/build_public_tmp/{flow_id}/flow with a benign data parameter and verify that attacker-supplied flow data is not accepted for execution. Confirm reverse proxies, ingress controllers, API gateways, and firewall rules do not expose the vulnerable endpoint unnecessarily. Validate that no unauthenticated public build path can execute dynamic Python code and that application logs no longer show successful unauthenticated build requests with caller-supplied data payloads.

Typical attack path

1. Scan for internet-facing or internally reachable Langflow instances.
2. Confirm the target exposes POST /api/v1/build_public_tmp/{flow_id}/flow without authentication.
3. Submit a crafted request containing the optional data parameter with malicious flow/node definitions.
4. Trigger Langflow to build the attacker-supplied flow instead of the stored public flow.
5. Execute arbitrary Python code through unsandboxed exec() in the Langflow application process.
6. Use Python code to run shell commands, read environment variables, access local files, or call internal services.
7. Exfiltrate credentials, API keys, workflow data, or connected service secrets.
8. Deploy additional tooling, establish persistence, pivot laterally, or disrupt operations.

How to detect it

Investigate whether the vulnerable endpoint was accessed before patching. Review HTTP access logs from Langflow, reverse proxies, load balancers, API gateways, WAFs, ingress controllers, and container sidecars for POST requests to /api/v1/build_public_tmp/{flow_id}/flow, especially from unknown IP addresses, high-volume scanners, or requests containing a data parameter. Inspect request bodies where available for Python execution patterns such as exec, __import__, os.system, subprocess, eval, open, socket, base64 decoding, shell invocations, or download commands. Correlate suspicious requests with Langflow application logs showing public flow builds, Python exceptions, stack traces, or unexpected node execution. On hosts and containers, review EDR, auditd, Sysmon, process accounting, shell history, and container runtime logs for the Langflow/Python process spawning operating system commands, shells, network utilities, interpreters, or file-transfer tools. Look for outbound connections shortly after suspicious POST requests, especially to unfamiliar IPs, paste sites, file servers, Tor/VPN infrastructure, or command-and-control-like endpoints. Because exploitation has been observed in the wild and associated reporting includes Interlock ransomware campaign activity, also hunt for post-exploitation behavior: credential discovery, archive creation, mass file access, lateral movement attempts, remote management tool deployment, backup deletion, and ransomware staging. If logs are limited or request bodies were not captured, treat any unauthenticated POSTs to the endpoint on a vulnerable instance as suspicious and expand the investigation around the timestamp.

• POST /api/v1/build_public_tmp/
• /api/v1/build_public_tmp/
• /api/v1/build_public_tmp/*/flow
• build_public_tmp
• "data"
• "exec("
• "__import__"
• "os.system"
• "subprocess"
• "eval("
• "base64.b64decode"
• "socket"
• "/bin/sh"
• "/bin/bash"
• "bash -c"
• "sh -c"
• "python -c"
• "curl "
• "wget "
• "nc "
• "ncat "
• "powershell"
• "cmd.exe"
• langflow
• python

What your security team should do

• Immediately inventory all Langflow deployments, including containers, developer servers, AI workflow platforms, internal tools, and internet-facing instances.
• Upgrade all affected Langflow instances to version 1.9.0 or later, prioritizing internet-exposed systems and environments with access to sensitive integrations.
• Treat exposed vulnerable instances as potentially compromised due to KEV status, active exploitation, and EPSS 0.99836.
• Search historical web, reverse proxy, API gateway, application, EDR, and container logs for requests to /api/v1/build_public_tmp/ with POST method and data payloads.
• Rotate credentials and tokens accessible to Langflow processes, especially API keys, database passwords, cloud credentials, model provider tokens, and workflow integration secrets.
• Restrict Langflow administrative and public build endpoints to trusted networks or authenticated access paths only.
• Hunt for child processes spawned by the Langflow or Python process, including shells, curl, wget, powershell, python -c, and other command execution patterns.
• Review hosts for persistence, unauthorized files, new scheduled tasks or cron jobs, outbound callbacks, and evidence of ransomware staging or lateral movement.
• Add SIEM detections for unauthenticated POST requests to the affected endpoint and for suspicious code execution strings in request bodies.
• If exploitation is suspected, isolate affected hosts, preserve logs and container images, collect forensic artifacts, and perform incident response before returning systems to service.