CVE-2026-33873 — langflow
CVE-2026-33873 is a Code Injection vulnerability in langflow. A fix is available for langflow — see the affected versions and patch details below.
Langflow has Authenticated Code Execution in Agentic Assistant Validation
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-33873.
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.
Real-World Exposure
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.0pip install --upgrade 'langflow==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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update langflow to 1.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33873 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-33873 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-33873. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-33873 in your dependencies?
O3 Security finds CVE-2026-33873 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.