GHSA-v8hw-mh8c-jxfc
Langflow has Authenticated Code Execution in Agentic Assistant Validation
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
langflowReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | langflow | all versions | 1.9.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for langflow. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update langflow to 1.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v8hw-mh8c-jxfc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-v8hw-mh8c-jxfc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-v8hw-mh8c-jxfc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-v8hw-mh8c-jxfc in your dependencies?
O3 detects GHSA-v8hw-mh8c-jxfc across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.