CVE-2026-101861 in Langflow
Summary
by MITRE • 09/28/2026
Langflow 1.0.16 before 1.12.0 and 0.0.94 before 1.12.0 contain an unsafe eval() vulnerability in schema.py that allows authenticated attackers to achieve code execution by placing a Python object with a malicious __repr__ method into component input options lists. The eval() sink is triggered when a component is converted into a LangChain tool via ComponentToolkit.get_tools(), including during custom component saves through the API, by interpolating options into a Literal type string that is passed directly to eval() without safe evaluation controls.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Langflow versions prior to 1.12.0 represents a critical server-side code execution flaw rooted in improper neutralization of special elements used within an expression, commonly categorized under CWE-95 as the Eval Injection weakness. This security defect resides specifically within the schema.py module and exploits the application's handling of component input options during the conversion process into LangChain tools via the ComponentToolkit.get_tools() method. The core technical issue arises when user-supplied data is interpolated directly into a Python Literal type string, which is subsequently passed to the built-in eval function without any sanitization or safe evaluation controls. This architectural decision allows an attacker who has successfully authenticated to the application to inject malicious Python code that will be executed in the context of the running server process.
The operational mechanism of this exploit relies on the specific behavior of Python's object representation methods, particularly _repr_. An authenticated adversary can craft a payload by placing a custom Python object containing a malicious _repr_ method into the input options list of a component. When the system attempts to serialize or convert these inputs for use as LangChain tools, it invokes eval() on the resulting string representation. Because the evaluation is performed without restrictions, the interpreter executes arbitrary commands defined within the injected payload rather than merely displaying text data. This bypasses standard security boundaries because the vulnerability does not require complex exploitation techniques; it leverages native language features that are misused due to insufficient input validation and unsafe coding practices regarding dynamic code execution.
The impact of this vulnerability is severe, as successful exploitation grants an attacker full remote code execution capabilities on the host system running Langflow. This level of access allows for comprehensive compromise of the underlying infrastructure, including the ability to read sensitive configuration files, exfiltrate data stored within the application's database or memory, install backdoors, and pivot into other network segments depending on the deployment environment. Since authentication is required to trigger this flaw, it primarily affects environments where user accounts are provisioned without strict privilege separation or multi-factor authentication enforcement. The vulnerability persists across both major version lines 1.x (specifically from 1.0.16 up to but not including 1.12.0) and the legacy 0.x line (from 0.0.94 up to but not including 1.12.0), indicating a systemic issue in how component schemas are processed across different release cycles of the software.
Mitigation strategies must prioritize immediate remediation through version upgrades, as the vulnerability is resolved in Langflow version 1.12.0 and later releases where the unsafe eval() calls have been replaced with safer alternatives or removed entirely. For organizations unable to upgrade immediately due to compatibility constraints, defensive coding practices should be implemented within custom integrations if possible, such as avoiding dynamic evaluation of user-supplied strings altogether. Additionally, implementing strict input validation that rejects any non-standard data types in component options lists can provide a layer of defense against this specific attack vector. Network-level controls like web application firewalls may offer limited protection by detecting patterns associated with Python object serialization payloads, but they are not a substitute for patching the underlying code flaw. Security teams should also audit existing deployments to ensure that only trusted users have authenticated access and that least-privilege principles are enforced to limit the blast radius in case of future vulnerabilities. This incident highlights the importance of adhering to secure coding standards such as those outlined in OWASP guidelines regarding dynamic evaluation, which explicitly warn against using eval() with untrusted input due to its inherent risks for code injection attacks aligned with ATT&CK techniques involving command and script interpretation.