CVE-2026-0769: langflow: Code Injection enables RCE

UNKNOWN CISA: TRACK*

Published January 23, 2026

CISO Take

Langflow deployments exposed to the internet are trivially exploitable for unauthenticated remote code execution — no credentials needed. Any org running Langflow as part of their AI pipeline infrastructure should treat this as a P0: patch or network-isolate immediately. Until patched, restrict Langflow to internal networks only and audit for indicators of compromise.

What is the risk?

Effective risk is CRITICAL despite missing CVSS score. The attack profile mirrors a 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H): network-reachable, no authentication, no user interaction, full process compromise. Langflow is widely deployed in enterprise AI pipeline prototyping and production agentic workflows, significantly expanding the attack surface. The eval() pattern on raw user input is a textbook CWE-95 with no compensating controls described. Exploitation complexity is trivially low — a crafted HTTP POST to the affected endpoint is sufficient.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Langflow	pip	—	No patch
149.9K Pushed 4d ago 40% patched ~67d to patch Full package profile →

Do you use Langflow? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

33.8%

chance of exploitation in 30 days

Higher than 98% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Possible

Exploitation: LOW

Sophistication

Trivial

Exploitation Confidence

low

✓ VulnCheck KEV (exploitation reported — broader/earlier than CISA) — Jun 2026

○ EPSS exploit prediction: 34%

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

6 steps

IMMEDIATE

Isolate all Langflow instances behind VPN or internal network — remove any public internet exposure.
PATCH

Apply vendor patch as soon as released; monitor ZDI advisory ZDI-26-035 and Langflow GitHub for patch ETA.
WORKAROUND (if patch unavailable): Disable custom component functionality via Langflow configuration or block the eval_custom_component_code API endpoint at the WAF/reverse proxy layer.
ROTATE CREDENTIALS

Assume any previously internet-exposed Langflow instance is compromised — rotate all LLM provider API keys, vector DB credentials, and any secrets accessible to the Langflow process.
DETECT

Search logs for anomalous outbound connections from Langflow hosts, unexpected process spawning, and unusual POST requests to component evaluation endpoints.
AUDIT

Review Langflow access logs for exploitation attempts — look for payloads containing import, os, subprocess, socket, or base64 patterns in component code fields.

What does CISA's SSVC say?

Decision Track*

Exploitation none

Automatable Yes

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Auth Bypass Data Extraction Framework Agent Plugin AML.T0010.001 - AI Software AML.T0049 - Exploit Public-Facing Application AML.T0050 - Command and Scripting Interpreter AML.T0053 - AI Agent Tool Invocation AML.T0055 - Unsecured Credentials AML.T0072 - Reverse Shell AML.T0083 - Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

6.1.2 - AI risk assessment 8.1 - Operational planning and control A.6.2.2 - AI System Security — Access Control A.6.2.6 - AI System Security — Input Validation

NIST AI RMF

GOVERN 1.7 - Processes for identifying and managing AI risks GOVERN 6.2 - Risk Management — Policies for AI system security MANAGE 2.2 - Mechanisms to sustain value of deployed AI systems

OWASP LLM Top 10

LLM02 - Insecure Output Handling LLM07 - Insecure Plugin Design LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-0769?

Is CVE-2026-0769 actively exploited?

No confirmed active exploitation of CVE-2026-0769 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-0769?

1. IMMEDIATE: Isolate all Langflow instances behind VPN or internal network — remove any public internet exposure. 2. PATCH: Apply vendor patch as soon as released; monitor ZDI advisory ZDI-26-035 and Langflow GitHub for patch ETA. 3. WORKAROUND (if patch unavailable): Disable custom component functionality via Langflow configuration or block the eval_custom_component_code API endpoint at the WAF/reverse proxy layer. 4. ROTATE CREDENTIALS: Assume any previously internet-exposed Langflow instance is compromised — rotate all LLM provider API keys, vector DB credentials, and any secrets accessible to the Langflow process. 5. DETECT: Search logs for anomalous outbound connections from Langflow hosts, unexpected process spawning, and unusual POST requests to component evaluation endpoints. 6. AUDIT: Review Langflow access logs for exploitation attempts — look for payloads containing import, os, subprocess, socket, or base64 patterns in component code fields.

What systems are affected by CVE-2026-0769?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM pipeline orchestration, no-code AI workflow builders, RAG pipelines using Langflow, model serving endpoints connected via Langflow.

What is the CVSS score for CVE-2026-0769?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM pipeline orchestrationno-code AI workflow buildersRAG pipelines using Langflowmodel serving endpoints connected via Langflow

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0049 Exploit Public-Facing Application

AML.T0050 Command and Scripting Interpreter

AML.T0053 AI Agent Tool Invocation

AML.T0055 Unsecured Credentials

AML.T0072 Reverse Shell

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: 6.1.2, 8.1, A.6.2.2, A.6.2.6

NIST AI RMF: GOVERN 1.7, GOVERN 6.2, MANAGE 2.2

OWASP LLM Top 10: LLM02, LLM07, LLM08

What are the technical details?

Original Advisory

Langflow eval_custom_component_code Eval Injection 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 implementation of eval_custom_component_code function. The issue results from the lack of proper validation of a user-supplied string before using it to execute python code. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26972.

Exploitation Scenario

An adversary scans for Langflow instances via Shodan or direct HTTP fingerprinting (Langflow exposes identifiable UI/API endpoints). Without any authentication, they craft an HTTP POST to the eval_custom_component_code endpoint containing a Python reverse shell payload (e.g., importing subprocess and connecting back to attacker-controlled infrastructure). The Langflow server evaluates the payload and executes it in-process. The attacker now has a shell running as the Langflow service account, reads environment variables and configuration files to harvest LLM API keys and database credentials, exfiltrates the keys, and installs a persistent backdoor. In an agentic deployment, the attacker may also modify pipeline logic to inject malicious instructions into LLM prompts, causing the AI agent to exfiltrate user data or take unauthorized actions on connected tools.

Weaknesses (CWE)

CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') Primary

CWE-95 — Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'): The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

[Architecture and Design, Implementation] If possible, refactor your code so that it does not need to use eval() at all.
[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.