Langflow has Authenticated Code Execution in Agentic Assistant Validation
Description
1. Summary
The Agentic Assistant feature in Langflow executes LLM-generated Python code during its validation phase. Although this phase appears intended to validate generated component code, the implementation reaches dynamic execution sinks and instantiates the generated class server-side.
In deployments where an attacker can access the Agentic Assistant feature and influence the model output, this can result in arbitrary server-side Python execution.
2. Description
2.1 Intended Functionality
The Agentic Assistant endpoints are designed to help users generate and validate components for a flow. Users can submit requests to the assistant, which returns candidate component code for further processing.
A reasonable security expectation is that validation should treat model output as untrusted text and perform only static or side-effect-free checks.
The externally reachable endpoints are:
The request model accepts attacker-influenceable fields such as input_value, flow_id, provider, model_name, session_id, and max_retries:
2.2 Root Cause
In the affected code path, Langflow processes model output through the following chain:
/assist
→ execute_flow_with_validation()
→ execute_flow_file()
→ LLM returns component code
→ extract_component_code()
→ validate_component_code()
→ create_class()
→ generated class is instantiated
The assistant service reaches the validation path here:
The code extraction step occurs here:
The validation entry point is here:
The issue is that this validation path is not purely static. It ultimately invokes create_class() in lfx.custom.validate, where Python code is dynamically executed via exec(...), including both global-scope preparation and class construction.
As a result, LLM-generated code is treated as executable Python rather than inert data. This means the “validation” step crosses a trust boundary and becomes an execution sink.
The streaming path can also reach this sink when the request is classified into the component-generation branch:
3. Proof of Concept (PoC)
- Send a request to the Agentic Assistant endpoint.
- Provide input that causes the model to return malicious component code.
- The returned code reaches the validation path.
- During validation, the server dynamically executes the generated Python.
- Arbitrary server-side code execution occurs.
4. Impact
-
Attackers who can access the Agentic Assistant feature and influence model output may execute arbitrary Python code on the server.
-
This can lead to:
- OS command execution
- file read/write
- credential or secret disclosure
- full compromise of the Langflow process
5. Exploitability Notes
This issue is most accurately described as an authenticated or feature-reachable code execution vulnerability, rather than an unconditional unauthenticated remote attack.
Severity depends on deployment model:
- In local-only, single-user development setups, the issue may be limited to self-exposure by the operator.
- In shared, team, or internet-exposed deployments, it may be exploitable by other users or attackers who can reach the assistant feature.
The assistant feature depends on an active user context:
Authentication sources include bearer token, cookie, or API key:
Default deployment settings may widen exposure, including AUTO_LOGIN=true and the /api/v1/auto_login endpoint:
6. Patch Recommendation
- Remove all dynamic execution from the validation path.
- Ensure validation is strictly static and side-effect-free.
- Treat all LLM output as untrusted input.
- If code generation must be supported, require explicit approval and run it in a hardened sandbox isolated from the main server process.
Discovered by: @kexinoh (https://github.com/kexinoh, works at Tencent Zhuque Lab)