CVE-2026-105699: Langflow Information Disclosure Vulnerability

CVE-2026-105699 Overview

CVE-2026-105699 is a broken access control vulnerability in Langflow, an open-source tool for building and deploying AI-powered agents and workflows. The flaw affects versions 1.6.8 through 1.9.0 and allows an authenticated user with access to any project-scoped Model Context Protocol (MCP) endpoint to read flow-backed files belonging to other users or projects. Langflow verified the project identifier on the MCP connection but failed to authorize the resource Uniform Resource Identifier (URI) passed to resources/read. The issue is fixed in version 1.9.1.

Critical Impact
Authenticated tenants can retrieve uploaded documents, structured data, prompts, and other private flow artifacts across tenant boundaries without modifying victim data.

Affected Products

Langflow versions 1.6.8 through 1.9.0
Langflow MCP project-scoped endpoints (handle_read_project_resource)
Multi-tenant Langflow deployments exposing MCP server interfaces

Discovery Timeline

2026-10-05 - CVE-2026-105699 published to the National Vulnerability Database (NVD)
2026-10-06 - Last updated in the NVD database

Technical Details for CVE-2026-105699

Vulnerability Analysis

The vulnerability resides in the MCP project resource handler at src/backend/base/langflow/api/v1/mcp_projects.py. When an authenticated client issued a resources/read request to a project-scoped MCP endpoint, Langflow authenticated the caller and resolved the project identifier bound to that connection. However, the handler passed the attacker-supplied URI directly to the global handle_read_resource function without constraining the lookup to the connection's project.

handle_read_resource parsed a flow_id and filename from the URI and forwarded the request to storage_service.get_file. The storage layer returned the file bytes without verifying that the referenced flow belonged to the authenticated user or the currently scoped project. This classifies as Authorization Bypass Through User-Controlled Key [CWE-639].

Complementing the read primitive, handle_list_resources and handle_list_tools returned flow and file identifiers across tenants, which made it straightforward for an attacker to enumerate valid targets before issuing the cross-tenant read.

Root Cause

The root cause is missing object-level authorization at the MCP resource boundary. The code trusted the connection-level project binding but never re-validated that the requested flow_id belonged to that project or user before dispatching to storage.

Attack Vector

An authenticated low-privilege user with access to any project-scoped MCP endpoint enumerates flow and file identifiers via handle_list_resources or handle_list_tools, then calls resources/read with a URI referencing another tenant's flow_id and filename. The server returns the file contents. The attack is read-only; stored flows and files are not modified.

python

        @self.server.read_resource()
        async def handle_read_project_resource(uri: str) -> bytes:
            """Handle resource read requests for this specific project."""
-            return await handle_read_resource(uri=uri)
+            return await handle_read_resource(uri=uri, project_id=self.project_id)

        @self.server.call_tool()
        @handle_mcp_errors

Source: GitHub Commit b8fe970. The patch forwards self.project_id so the downstream handler can enforce that the parsed flow_id belongs to the current project.

Detection Methods for CVE-2026-105699

Indicators of Compromise

MCP resources/read requests whose URI-embedded flow_id does not belong to the authenticated user's projects.
Repeated handle_list_resources or handle_list_tools calls followed by read_resource calls referencing newly enumerated identifiers.
Access patterns where a single authenticated principal reads files across multiple distinct flow_id values in a short window.

Detection Strategies

Log every MCP resources/read invocation with the authenticated user, connection-scoped project_id, and the parsed flow_id and filename from the URI.
Alert when the parsed flow_id resolves to a project the caller does not own or belong to.
Correlate enumeration (list_resources, list_tools) with subsequent reads of previously unseen flow identifiers by the same principal.

Monitoring Recommendations

Instrument storage_service.get_file calls with user and project context for post-hoc tenant-boundary audits.
Track Langflow version strings in deployment inventories and flag any instance between 1.6.8 and 1.9.0.
Baseline normal per-user flow access volume and alert on deviations consistent with cross-tenant enumeration.

How to Mitigate CVE-2026-105699

Immediate Actions Required

Upgrade Langflow to version 1.9.1 or later, which enforces project scoping in handle_read_project_resource.
Rotate any secrets, API keys, or credentials that may have been embedded in prompts, uploaded documents, or flow artifacts on affected instances.
Audit MCP access logs for cross-tenant flow_id reads during the exposure window.

Patch Information

The fix is delivered in GitHub Release v1.9.1 via GitHub Pull Request #12818 and commits b8fe970 and f0fd436. Technical context is published in the GitHub Security Advisory GHSA-4hmc-cfm3-w43c.

Workarounds

Restrict MCP endpoint access to trusted single-tenant deployments until the upgrade to 1.9.1 is complete.
Place MCP endpoints behind a reverse proxy that enforces per-user project allowlists on resources/read URIs.
Disable project-scoped MCP connections for untrusted or shared-tenant users where feasible.

bash

# Upgrade Langflow to the patched release
pip install --upgrade "langflow>=1.9.1"

# Verify the installed version
python -c "import langflow; print(langflow.__version__)"