CVE-2026-105699 in Langflow
Summary
by MITRE • 10/06/2026
Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.6.8 until 1.9.1, Langflow authenticated access to the project identifier in a project-scoped MCP connection but did not authorize the resource URI supplied to resources/read. read_resource forwarded the attacker-controlled URI to handle_read_resource, which parsed a flow_id and filename and called storage_service.get_file without verifying that the flow belonged to the authenticated user or current project. A user with access to any project-scoped MCP endpoint could therefore request another user's flow-backed file, while global handle_list_resources and handle_list_tools behavior could disclose flow and file identifiers that made targeting easier. The vulnerability disclosed uploaded documents, structured data, prompts, and other private flow artifacts across tenants but did not modify victim files or stored flows. This issue is fixed in version 1.9.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
Langflow serves as a platform for constructing and deploying artificial intelligence agents and workflows, yet versions ranging from 1.6.8 through 1.9.1 contained a critical authorization flaw within its Model Context Protocol implementation that allowed unauthorized access to sensitive data across tenant boundaries. The vulnerability stems from an inconsistency in how the application handles authentication versus authorization when processing requests for project-scoped connections. While the system correctly authenticated users attempting to access specific project identifiers, it failed to enforce proper resource-level permissions when handling subsequent read operations on those resources. This architectural gap created a scenario where valid credentials could be leveraged to bypass logical security controls designed to isolate data between different projects and users within the multi-tenant environment.
The technical root cause lies in the execution flow of the read_resource function, which forwards attacker-controlled Uniform Resource Identifiers directly to handle_read_resource without performing adequate validation checks. Upon receiving these requests, the system parses a flow identifier and filename from the URI but proceeds to call storage_service.get_file without verifying that the requested flow actually belongs to the authenticated user or is associated with their current project context. This lack of ownership verification means that any individual granted access to a single project-scoped MCP endpoint can manipulate resource URIs to target files belonging to other users or projects, effectively bypassing the intended isolation mechanisms provided by the platform's multi-tenancy architecture.
The operational impact of this vulnerability is significant as it enables cross-tenant data leakage without requiring privilege escalation or code execution capabilities. An attacker with access to any project-scoped MCP endpoint can enumerate and retrieve private flow artifacts from other tenants, including uploaded documents, structured datasets, prompt templates, and other confidential workflow components. Although the flaw does not permit modification of victim files or stored flows, which limits the risk of data corruption or system compromise, it represents a severe confidentiality breach that could expose proprietary algorithms, sensitive business logic, or personally identifiable information depending on the content stored within the affected Langflow instances.
The attack surface is further expanded by the behavior of global handle_list_resources and handle_list_tools functions, which disclose flow and file identifiers to authenticated users regardless of their specific project permissions. This enumeration capability simplifies targeting for attackers by revealing valid resource paths that can then be exploited through the aforementioned authorization bypass in the read operation. The combination of information disclosure via listing endpoints and unauthorized access via reading endpoints creates a complete data exfiltration pathway, allowing adversaries to systematically harvest sensitive artifacts from multiple tenants using minimal initial foothold requirements within any single project scope.
This vulnerability aligns with CWE-269, which describes Improper Privilege Escalation, specifically in the context of vertical privilege escalation where an actor uses lower-level privileges to access resources intended for higher-level or different actors. It also maps closely to CWE-862, Missing Authorization, as the application fails to enforce proper checks on user input before granting access to protected data. From a tactical perspective, this behavior corresponds to ATT&CK technique T1074, Data Staged, and potentially T1530, Data from Cloud Storage Object Buckets, depending on how Langflow integrates with external storage backends, highlighting the risk of sensitive data being extracted by unauthorized actors through API manipulation.
To mitigate this issue, organizations must immediately upgrade to version 1.9.1 or later where the authorization logic has been corrected to verify flow ownership before granting file access. Until an upgrade is feasible, administrators should restrict network-level access to Langflow MCP endpoints to only those users who absolutely require it and ensure that no sensitive data requiring strict isolation is stored within projects accessible via these interfaces. Implementing additional API gateway rules or custom middleware to validate resource ownership against user identity prior to invoking storage services can provide a compensating control, though upgrading remains the definitive remediation strategy for this architectural flaw in the access control model.