CVE-2026-105698: Missing Authorization in Deprecated Chat Vertices Endpoints in Langflow

CVE-2026-105698 is a missing authorization vulnerability affecting Langflow, a widely utilized orchestrator for constructing and executing artificial intelligence agent workflows. The flaw resides in deprecated endpoints that remain active within the application routing configuration. Specifically, the endpoints POST /api/v1/build/{flow_id}/vertices and POST /api/v1/build/{flow_id}/vertices/{vertex_id} fail to validate whether the requesting user owns the requested flow resource. This flaw allows unauthorized network actors who know or retrieve the unique identifier of a private flow to interact with the underlying execution engine.

The affected endpoints belong to the chat execution service, which manages the compilation and progressive execution of workflow graphs. In typical web architectures, deprecating an endpoint involves removing it from active route schemas or client libraries. However, within the FastAPI framework, designating a route as deprecated or omitting it from the OpenAPI schema merely hides the path from client documentation without disabling the associated handler. Consequently, these endpoints remained exposed to incoming network connections, presenting an unmonitored attack surface.

This vulnerability is classified under CWE-862 (Missing Authorization) and CWE-639 (Authorization Bypass Through User-Controlled Key). The severity is amplified by the fact that earlier versions (prior to version 1.7.2) allowed completely unauthenticated access to these routes. In versions 1.7.2 through 1.10.0, the endpoints required user authentication but omitted granular ownership validation, meaning any authenticated user could query and execute the flows of other users on the same system.

The underlying cause of CVE-2026-105698 is a database querying pattern that lacks user-scoping constraints. When an API client targets the endpoints mapped to the retrieve_vertices_order and build_vertex handlers, the application retrieves the requested flow database record using only the primary key flow_id supplied in the request path. Because the lookup pattern did not join the flow table with the current user identity or verify the owner identifier field, the application constructed the entire graph structure in memory on behalf of any requester.

In the vulnerable architecture, the execution engine calls helper functions such as build_graph_from_db_no_cache to resolve database entities. These helper components execute a lookup against the SQL database, retrieving configuration parameters, component configurations, and environment variables configured by the original author. If an attacker submits a valid flow UUID, the engine loads the target flow, builds the object representation, caches the parsed structure, and exposes its functional nodes.

The secondary cause is the lack of integration with Langflow's access control framework. Prior to version 1.10.1, the application lacked a formalized, pluggable Role-Based Access Control layer capable of intercepting route execution. As a result, the handlers proceeded directly from simple parameter verification to deep execution logic without evaluating authorization rules. This omission allowed any authenticated entity to simulate step-by-step executions of target nodes.

The remediation of CVE-2026-105698, introduced in commit fb3d6ec90b1e4d52eaa40915a64b1f86b6542f55, involves restructuring the database lookup and inserting strict authorization checks. In the patched implementation, the application rejects the use of simple primary-key queries and instead employs scoped select statements that filter by both the requested resource identifier and the authenticated user's database identifier. The application also forces an explicit permission check before processing the request.

The following comparative code block illustrates the vulnerability remediation within src/backend/base/langflow/api/v1/chat.py:

# Vulnerable Code Path (Pre-Patch)
# The application retrieved the flow directly, assuming authentication was sufficient.
@router.post("/build/{flow_id}/vertices", deprecated=True, include_in_schema=False)
async def retrieve_vertices_order(
    *,
    flow_id: UUID,
    stop_component_id: str | None = None,
    start_component_id: str | None = None,
    session: DbSession,
) -> VerticesOrderResponse:
    # Direct database lookup without filtering by ownership
    flow = session.get(Flow, flow_id)
    if not flow:
        raise HTTPException(status_code=404, detail="Flow not found")
    # Proceed to build vertices without checking permissions...
 
 
# Patched Code Path (Post-Patch in Commit fb3d6ec90b1e4d52eaa40915a64b1f86b6542f55)
# Scoped query verifies ownership, and RBAC rules are explicitly validated.
@router.post("/build/{flow_id}/vertices", deprecated=True, include_in_schema=False)
async def retrieve_vertices_order(
    *,
    flow_id: UUID,
    stop_component_id: str | None = None,
    start_component_id: str | None = None,
    session: DbSession,
    current_user: CurrentActiveUser, # Inject authenticated identity
) -> VerticesOrderResponse:
    # Query constrained by ownership or public access configuration
    stmt = (
        select(Flow)
        .where(Flow.id == flow_id)
        .where((Flow.user_id == current_user.id) | (Flow.access_type == AccessTypeEnum.PUBLIC))
    )
    flow = (await session.exec(stmt)).first()
    if not flow:
        # Return generic 404 to prevent enumeration of existing UUIDs
        raise HTTPException(status_code=404, detail=f"Flow with id {flow_id} not found")
        
    # Enforce Role-Based Access Control
    await ensure_flow_permission(
        current_user,
        FlowAction.EXECUTE,
        flow_id=flow_id,
        flow_user_id=flow.user_id,
        workspace_id=flow.workspace_id,
        folder_id=flow.folder_id,
    )
    # Safe to proceed with vertices build order retrieval...

This fix is highly robust and complete. By returning a generic 404 Not Found response when a flow is either missing or owned by another user without public access, the system eliminates side-channel UUID enumeration. This design prevents an attacker from verifying the existence of particular flow instances. Additionally, integrating the centralized ensure_flow_permission security guard guarantees that authorization rules remain uniform across both current and legacy endpoints.

Exploiting CVE-2026-105698 requires that the attacker identifies or guesses the 128-bit UUID of a target private flow. Because UUIDs are globally unique, the risk of random brute-force attacks is minimal unless the identifiers are exposed through side channels. However, if the victim's environment exposes these identifiers via browser history, application logs, database exports, or network metadata, the attacker can use them to query the vulnerable endpoints.

Once the target flow UUID is acquired, the attacker transmits a structured POST request to /api/v1/build/{flow_id}/vertices. In versions prior to 1.7.2, this request could be sent over the network without headers. In versions 1.7.2 through 1.10.0, the attacker must first register a low-privilege account on the target Langflow instance, generate a JSON Web Token (JWT), and attach it as a bearer token. The application processes the request, loads the target graph, and returns the full sequential array of vertex identifiers, exposing the component structure of the private workflow.

With the list of vertex identifiers in hand, the attacker can selectively trigger executions of individual components. By issuing subsequent POST requests to /api/v1/build/{flow_id}/vertices/{vertex_id}, the attacker instructs the backend to execute the specified module. If the targeted node is programmed to execute python commands, read local files, or call downstream APIs, the execution runs within the security context of the Langflow server, producing unauthorized side effects and returning output data directly to the attacker.

The impact of this vulnerability is significant, but restricted to specific operations. Exploitation leads to information disclosure concerning the internal topology of private workflows, including the names and configuration schemas of database adapters, prompt templates, and custom script blocks. The attacker can read the execution outputs of specific components, which may contain sensitive database queries, processed user logs, or intermediate agent decisions.

In terms of integrity, triggering the compilation and execution of vertices can cause unapproved side effects. These side effects include writing unauthorized data to connected databases, issuing unauthorized external API calls, and generating fictitious entries in the local build history. However, the flaw does not allow the attacker to permanently modify the stored graph files or inject arbitrary code into the workflow configuration database. Furthermore, credentials stored securely within the primary variable manager are not directly exposed by this vulnerability.

The CVSS v3.1 score of 5.4 reflects this scope of compromise. The vector elements indicate network availability (AV:N), low complexity (AC:L), low privilege requirements (PR:L), and no user interaction (UI:N). The confidentiality and integrity impacts are evaluated as low (C:L/I:L), while availability remains unaffected (A:N). The vulnerability represents a serious access control bypass but does not provide direct system-level administrative access.

The primary remediation strategy is upgrading the deployment to a supported and secure version of the software. Organizations running Langflow must upgrade to version 1.10.1 or higher. Developers who integrate the platform using dependency managers must ensure that the underlying package langflow-base is updated to version 0.10.1 or higher. Upgrading introduces the formal authorization service and applies the ownership database query filters across all endpoints.

For systems where immediate upgrades are not feasible due to testing constraints, virtual patching provides temporary protection. Administrators should deploy an ingress filter or a reverse proxy configuration, such as Nginx, to intercept and block all traffic targeting the deprecated paths. Because these endpoints are deprecated and replaced by modern API routes, blocking them will not degrade normal application workflows or disrupt standard user interactions.

Deploying Web Application Firewall (WAF) rules serves as an additional defensive layer. Custom signatures should be configured to detect and reject HTTP request patterns that target the paths matching /api/v1/build/.*vertices. This block pattern stops the exploitation chain at the network edge before the application routing engine processes the request.