Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain victim flow UUID
-
DeliveryAuthenticate as low-privilege user (or unauthenticated ≤1.7.1)
-
ExploitCall deprecated POST build vertices endpoint
-
Executionretrieve_vertices_order loads private graph, enumerate vertices
-
Impactbuild_vertex executes vertices, exfiltrate structure and outputs
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | The attacker must know the victim's flow UUID (an unguessable identifier obtained out-of-band, through disclosure, or enumeration) and the target must be running a version in the 1.0.0-1.10.0 range with the deprecated POST /api/v1/build/{flow_id}/vertices and /vertices/{vertex_id} handlers still reachable. On versions through 1.7.1, NO authentication is required; from 1.7.2 through 1.10.0, the caller needs only a valid authenticated account with no elevated privileges. Exploitation is most meaningful on shared/multi-user instances. Limiting factors capping impact: the flaw does NOT expose the victim's variable-store credentials and does NOT allow modification of the stored flow (read, enumerate, and execute only), and it is remediated in 1.10.1 / langflow-base 0.10.1. |
| Impact | This is a broken object-level authorization flaw (CWE-639, an IDOR) in Langflow's deprecated build-vertices endpoints, where build_graph_from_db_no_cache performed a primary-key lookup with no owner filter. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N = 5.4 Medium) reflects network reachability, low attack complexity, and no user interaction, but assumes PR:L (an authenticated low-privilege account). Critically, the description reveals a version-dependent privilege requirement the single CVSS vector obscures: through 1.7.1 the handlers were reachable completely UNAUTHENTICATED (effectively PR:N, raising real risk toward ~6.5), while 1.7.2 through 1.10.0 require any authenticated-but-unprivileged account (PR:L). No EPSS score, KEV listing, or public POC is present in the input, so there is no evidence of active or at-scale exploitation; this signals a real but not urgent priority. The primary limiters are that the attacker must already know a victim's flow UUID (an unguessable value absent enumeration or disclosure) and that impact is read/execute only - the input explicitly states the flaw did NOT expose variable-store credentials and did NOT permit modification of the stored flow, which correctly caps confidentiality and integrity at Low. Net: a legitimate medium-severity authorization gap worth patching promptly in multi-tenant/shared Langflow deployments, but not a high-urgency, widely-weaponized emergency. |
| Exploit ScenarioDerived | In a shared or multi-tenant Langflow instance, a low-privileged authenticated user (or, on versions through 1.7.1, an unauthenticated network caller) who has learned another user's flow UUID sends a POST to the deprecated /api/v1/build/{flow_id}/vertices endpoint. retrieve_vertices_order loads and caches the victim's private graph, the attacker enumerates vertex IDs, then invokes build_vertex to execute chosen vertices and read their outputs, disclosing private flow structure, configured values, and results while also triggering victim-configured side effects and build-history records. No public exploit was identified at the time of analysis, so exploitation requires custom tooling against these specific handlers. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 05, 2026
Private AI workflow data in Langflow 1.0.0 through 1.10.0 can be read, enumerated, and partially executed by a caller who knows the target flow's UUID, because the deprecated POST /api/v1/build/{flow_id}/vertices and /vertices/{vertex_id} handlers never verified flow ownership. Through 1.7.1 these handlers were reachable without authentication, while in 1.7.2 through 1.10.0 the attacker must be authenticated but needs no elevated privileges, consistent with the assessed CVSS:3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N (score 5.4). Impact is deliberately bounded: a caller can disclose private flow structure, configured values, and selected vertices' outputs and can trigger victim-configured side effects and build-history records, but cannot read the victim's variable-store credentials or modify the stored flow. No public exploit code identified at time of analysis, and the issue is fixed in Langflow 1.10.1 / langflow-base 0.10.1.
RemediationAI
Upgrade to Langflow 1.10.1 (or langflow-base 0.10.1) as the vendor-released patch, which introduces the ownership checks needed on the build-vertices handlers and aligns with the advisory at https://github.com/langflow-ai/langflow/security/advisories/GHSA-gh98-4phw-6fmw, the release at https://github.com/langflow-ai/langflow/releases/tag/v1.10.1, PR https://github.com/langflow-ai/langflow/pull/13153, and commit https://github.com/langflow-ai/langflow/commit/fb3d6ec90b1e4d52eaa40915a64b1f86b6542f55. If an immediate upgrade is not possible, block or restrict the deprecated POST /api/v1/build/{flow_id}/vertices and /api/v1/build/{flow_id}/vertices/{vertex_id} paths at the reverse proxy or network layer and require authentication at the edge - the trade-off is that legitimate in-app graph execution through those legacy routes will break for users, so restrict rather than delete the paths unless the deployment does not need them. On versions through 1.7.1, treat the instance as unauthenticated-exposed for this surface and reduce network reachability to trusted users; on 1.7.2-1.10.0, ordinary authenticated accounts must be considered capable of this access, so validate user-roster trust. Do not rely on enabling LANGFLOW_AUTHZ_ENABLED alone: in open-source deployments the shipped authorization service is a pass-through that allows every check, so real enforcement requires the enterprise plugin or the version that carries this vulnerability's code fix; enabling the flag without the enterprise plugin does not remediate the issue and only delays, rather than resolves, the exposure.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Langflow is a low-code platform for building and deploying AI-powered agents and workflows, where each flow is a directed graph of 'vertices' (nodes) plus configured values and outputs. The deprecated build endpoints POST /api/v1/build/{flow_id}/vertices and /api/v1/build/{flow_id}/vertices/{vertex_id} back the graph-building process: retrieve_vertices_order loads and caches the private graph and enumerates its vertex identifiers, and build_vertex executes selected vertices and returns their results. The root defect is CWE-639 (Authorization Bypass Through User-Controlled Key) - an insecure direct object reference - because build_graph_from_db_no_cache resolved the flow by primary key with no owner filter, so any caller who supplied a known flow_id obtained access to a graph they did not own. The CVE is tagged as an Authentication Bypass; in practice the pre-1.7.2 behavior allowed unauthenticated access to these handlers, and the 1.7.2-1.10.0 behavior allowed any authenticated user to reach them, which is why the published vector carries PR:L rather than PR:N. The upstream fix (commit fb3d6ec90b1e4d52eaa40915a64b1f86b6542f55, PR 13153) adds ownership checks and lands alongside a broader plannable authorization (RBAC) layer using ensure_flow_permission/ensure_flow_permission-style route guards built on a BaseAuthorizationService interface, with audit rows (authz_audit_log) and optionally Casbin rules. Notably, that authorization layer defaults to off (LANGFLOW_AUTHZ_ENABLED=false) and the open-source stub is a pass-through that returns allow for every check, so real allow/deny enforcement depends on the enterprise plugin or on the specific ownership checks added in this fix.
Know when Langflow gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Network endpoint, low complexity, PR:L reflects the authenticated 1.7.2-1.10.0 case; C:L for private flow/value disclosure, I:L for side effects and build-history writes, A:N as no availability impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
1DescriptionCVE.org
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.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Langflow before 1.3.0 allows unauthenticated remote code injection through the /api/v1/validate/code endpoint, enabling
Langflow has a third RCE vulnerability via exec_globals (EPSS 10.0%) allowing inclusion of untrusted code that executes
Account takeover and remote code execution in Langflow AI workflow platform versions ≤1.6.9 due to a CORS misconfigurati
Langflow has a code injection vulnerability in the code component (EPSS 2.6%) enabling remote code execution through the
Langflow has an eval injection in eval_custom_component_code (EPSS 2.0%) enabling remote code execution through crafted
Remote code execution in IBM Langflow OSS 1.0.0 through 1.9.3 lets an unauthenticated attacker inject and run arbitrary
Code injection in Langflow CSV Agent node before 1.8.0. The node hardcodes allow_dangerous_code=True, enabling arbitrary
Langflow through 0.6.19 allows remote code execution if untrusted users are able to reach the "POST /api/v1/custom_compo
OS command injection in Langflow's MCP stdio transport allows an attacker who can reach the MCP server configuration end
langflow <=1.0.18 is vulnerable to Remote Code Execution (RCE) as any component provided the code functionality and the
langflow v1.0.12 was discovered to contain a remote code execution (RCE) vulnerability via the PythonCodeTool component.
Langflow before 1.7.0.dev45 exposes multiple API endpoints without authentication, allowing unauthenticated access to us
EUVD-2026-92790
GHSA-gh98-4phw-6fmw
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB