CVE-2026-0770: Langflow affected by Remote Code Execution via validate_code() exec()

Langflow validates custom component code by running it. The public proof of concept points at validate_code() in src/lfx/src/lfx/custom/validate.py. That function calls exec() on user-supplied function definitions with no sandbox. Python evaluates default-argument expressions when it defines a function, so code placed in a default argument runs during validation, before any check can reject it. ZDI describes the same flaw as the handling of the exec_globals parameter passed to the validate endpoint.

The PoC lists these entry points: POST /api/v1/validate/code, POST /api/v1/custom_component, POST /api/v1/custom_component/update, POST /api/v1/webhook/{flow_id} and POST /api/v1/build_public_tmp/{flow_id}/flow. The last two need no authentication. For the others, the PoC says login can be bypassed when AUTO_LOGIN=true, which it calls the default configuration. ZDI says no authentication is required.

The attacker needs network access to the Langflow port. They get code execution on the host in the context of the Langflow process, which ZDI says is root. That exposes API keys for LLM providers, vector stores and databases kept in flows and environment, and gives a base for moving inward. EPSS is 0.6256, which is high.

The pip package langflow at version 1.7.3 and earlier. ZDI reported the flaw in July 2025, and the PoC author tested the langflowai/langflow:latest Docker image on 7 February 2026, so later builds may still be affected until the vendor ships a fix. Instances reachable from untrusted networks, with AUTO_LOGIN=true or with public flows, are the most exposed.

pip show langflow

For Docker, check the image tag and run the same command inside the container.

No patched version is listed in the advisory data. ZDI's page also gives no fixed version, and shows the vendor did not answer its follow-ups in the disclosure timeline. Check the Langflow releases and GitHub advisory for a fix before relying on this.

Mitigation from ZDI: restrict interaction with the product. In practice, that means taking Langflow off the public internet, putting it behind a VPN or an authenticating proxy, and blocking the endpoints listed above at the proxy.

The PoC page also points to turning AUTO_LOGIN off and not exposing public flows that hold code components. That page does not itself confirm those stop the attack, so verify them.

CISA's required action: apply vendor mitigations per BOD 26-04 and the forensics triage requirements, or stop using the product if no mitigation exists. The due date was 2026-07-24 and binds US federal agencies.

Check web or proxy logs for POSTs to /api/v1/validate/code, /api/v1/custom_component, /api/v1/custom_component/update, /api/v1/webhook/ and /api/v1/build_public_tmp/ from unknown addresses. Look in request bodies for function definitions whose default arguments call os, subprocess, __import__ or eval.

On the host, look for child processes of the Langflow server such as sh, curl, wget or python -c, for new files in /tmp and the working directory, new cron jobs or SSH keys, and outbound connections to unknown hosts. Because the process may run as root, treat a hit as full host compromise: rotate every API key and secret the instance could read.

Langflow exec_globals Inclusion of Functionality from Untrusted Control Sphere Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Langflow. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the handling of the exec_globals parameter provided to the validate endpoint. The issue results from the inclusion of a resource from an untrusted control sphere. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-27325.