CVE-2026-105698 in Langflow
Summary
by MITRE • 10/06/2026
Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.0.0 until 1.10.1, Langflow did not verify flow ownership in the deprecated POST /api/v1/build/{flow_id}/vertices and POST /api/v1/build/{flow_id}/vertices/{vertex_id} handlers. Through version 1.7.1, an unauthenticated caller who knew another user's flow UUID could reach these handlers; from version 1.7.2 through 1.10.0, callers had to authenticate but needed no elevated privileges. Such a caller could cause retrieve_vertices_order to load and cache the private graph, enumerate its vertex identifiers, and use build_vertex to execute selected vertices and receive their results. build_graph_from_db_no_cache performed a primary-key lookup without an owner filter. This could disclose private flow structure, configured values, and selected outputs and could trigger victim-configured side effects and build-history records, although it did not expose the victim's variable-store credentials or permit modification of the stored flow. This issue is fixed in Langflow 1.10.1 and langflow-base 0.10.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
Langflow serves as a platform for constructing and deploying artificial intelligence-powered agents and automated workflows, yet versions ranging from 1.0.0 through 1.10.1 contained significant access control deficiencies within its API endpoints responsible for processing flow components. The core technical flaw resides in the deprecated POST handlers located at /api/v1/build/{flow_id}/vertices and /api/v1/build/{flow_id}/vertices/{vertex_id}, which failed to adequately verify that the requesting user was the legitimate owner of the specified workflow graph. This lack of proper authorization checks allowed unauthorized entities to interact with private flow structures, leading to both information disclosure and potential execution of unintended operations within the victim's environment.
The operational impact varied slightly depending on the specific version in use due to changes in authentication requirements. In versions up through 1.7.1, the vulnerability was severe enough that unauthenticated attackers could exploit it simply by knowing another user's flow UUID. From version 1.7.2 through 1.10.0, while an authenticated session was required, no elevated privileges were necessary for exploitation; any valid user account with knowledge of a target flow ID could initiate the attack. This distinction highlights that even basic authentication is insufficient when underlying resource ownership validation is absent in critical API endpoints.
Exploitation of this vulnerability enabled attackers to perform several harmful actions against victim workflows. By invoking these handlers, an attacker could trigger the retrieve_vertices_order function, which would load and cache the private graph structure into memory. This allowed for the enumeration of all vertex identifiers within the flow, effectively revealing the internal architecture and logic of the workflow. Furthermore, the build_vertex endpoint permitted the execution of selected vertices using the victim's configuration. Consequently, attackers could cause side effects defined by the victim’s setup and generate entries in the build history logs, potentially disrupting operational continuity or creating forensic artifacts that obscure malicious activity.
The root cause is identified as a failure to implement proper object-level access control checks during database queries and graph processing routines. Specifically, functions such as build_graph_from_db_no_cache performed primary-key lookups without applying filters based on flow ownership. This architectural oversight meant that the system treated any valid request for a known ID as legitimate, regardless of whether the requester had permission to view or modify that specific resource. The vulnerability aligns with CWE-284 Improper Access Control and is categorized under ATT&CK technique T1530 Data from Cloud Storage Object Discovery if viewed through the lens of data exfiltration, though it more directly maps to unauthorized access patterns found in web application frameworks.
While the exploitation did not result in the exposure of sensitive variable-store credentials or allow direct modification of the stored flow definitions, the disclosure of private flow structure and configured values remains a critical security risk. Attackers could infer business logic, third-party integrations, and potentially sensitive data processing steps from the revealed graph topology and outputs. The issue has been remediated in Langflow version 1.10.1 and langflow-base 0.10.1 by implementing strict ownership verification before executing any build or vertex retrieval operations. Organizations running affected versions should upgrade immediately to ensure that API endpoints enforce proper authorization checks, preventing unauthorized enumeration and execution of workflow components.