Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-05T21:16:35.257Z",
  "pubdate": "2026-10-05T21:16:35.257Z",
  "executiveSummary": "Langflow versions 1.0.0 through 1.10.1 are susceptible to an Insecure Direct Object Reference (IDOR) vulnerability originating from insufficient authorization checks within specific API handlers.\nThe vulnerability resides in the POST /api/v1/build/{flow_id}/vertices and POST /api/v1/build/{flow_id}/vertices/{vertex_id} endpoints, which failed to validate flow ownership against the authenticated user or allow unauthenticated access to flows via UUID discovery.\nSuccessful exploitation permits unauthorized actors to interact with private flow objects, resulting in the unauthorized retrieval of graph structures, disclosure of configured values, and the triggering of arbitrary vertex execution.\nWhile the vulnerability does not grant access to credential stores or permit persistent modification of flow definitions, it allows for information leakage and the invocation of side effects associated with the victim's workflows.\nThis issue exposes organizations to unintended resource consumption, sensitive data exposure within flow configurations, and unauthorized execution of automated logic. Users are advised to upgrade to Langflow 1.10.1 and langflow-base 0.10.1 to remediate this flaw.",
  "technicalDetails": "The vulnerability stems from improper access control in the Langflow build pipeline, specifically within the POST /api/v1/build/{flow_id}/vertices and POST /api/v1/build/{flow_id}/vertices/{vertex_id} handlers.\nThe root cause is the failure of these endpoints to perform rigorous ownership validation. In versions 1.0.0 through 1.7.1, the lack of authentication allowed unauthenticated actors to access flows by merely knowing the target flow's UUID. From 1.7.2 through 1.10.0, the vulnerability persisted as an IDOR, where authenticated users could access flows owned by other users because the backend failed to enforce strict authorization filters.\nThe vulnerable code path involves the function build_graph_from_db_no_cache, which executes a database lookup using the flow UUID as a primary key without verifying the ownership metadata. Consequently, when an attacker provides a known flow_id, the system loads the private graph into memory and caches it, inadvertently exposing the flow's internal structure.\nThe attack flow follows a structured progression: First, an attacker identifies or guesses a valid target flow UUID. Second, by invoking the aforementioned build endpoints, the attacker forces the application to load the victim's graph. Third, the attacker leverages retrieve_vertices_order to enumerate vertex identifiers, revealing the specific nodes present in the workflow. Finally, by interacting with build_vertex, the attacker triggers the execution of selected vertices.\nThis execution leads to several negative impacts: it forces the application to compute outputs using victim-configured parameters, discloses output data resulting from these executions, and triggers side effects defined in the workflow. Furthermore, these actions are logged in the victim's build-history records, potentially causing confusion or masking legitimate activity. Although the vulnerability allows for unauthorized execution and data discovery, it remains constrained; it does not grant the attacker access to secure variable stores (credentials) or the ability to modify the permanent structure of the stored flow in the underlying database.\nThis flaw underscores the importance of enforcing server-side authorization checks for every request involving user-specific objects, ensuring that the identity of the requester is cross-referenced with the resource owner before any database operations or graph evaluations are performed."
}