<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 08 Oct 2026 02:03:02 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-105699</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-105699</link>
      <description>&lt;p&gt;Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.6.8 until 1.9.1, Langflow authenticated access to the project identifier in a project-scoped MCP connection but did not authorize the resource URI supplied to resources/read. read_resource forwarded the attacker-controlled URI to handle_read_resource, which parsed a flow_id and filename and called storage_service.get_file without verifying that the flow belonged to the authenticated user or current project. A user with access to any project-scoped MCP endpoint could therefore request another user&amp;#39;s flow-backed file, while global handle_list_resources and handle_list_tools behavior could disclose flow and file identifiers that made targeting easier. The vulnerability disclosed uploaded documents, structured data, prompts, and other private flow artifacts across tenants but did not modify victim files or stored flows. This issue is fixed in version 1.9.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Langflow is a tool for building and deploying AI-powered agents and workflows. From 1.6.8 until 1.9.1, Langflow authenticated access to the project identifier in a project-scoped MCP connection but did not authorize the resource URI supplied to resources/read. read_resource forwarded the attacker-controlled URI to handle_read_resource, which parsed a flow_id and filename and called storage_service.get_file without verifying that the flow belonged to the authenticated user or current project. A user with access to any project-scoped MCP endpoint could therefore request another user&amp;#39;s flow-backed file, while global handle_list_resources and handle_list_tools behavior could disclose flow and file identifiers that made targeting easier. The vulnerability disclosed uploaded documents, structured data, prompts, and other private flow artifacts across tenants but did not modify victim files or stored flows. This issue is fixed in version 1.9.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-105699</guid>
    </item>
    <item>
      <title>GHSA-4hmc-cfm3-w43c — Langflow has Authenticated Cross-Project File Disclosure via Unscoped MCP Resource Handlers</title>
      <link>https://db.gcve.eu/vuln/ghsa-4hmc-cfm3-w43c</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: langflow&lt;/p&gt;
&lt;p&gt;### Summary
Langflow&amp;#39;s project-scoped MCP transport authenticates the caller for the `project_id` in the connection URL, but the subsequent `resources/read` operation does not authorize the resource URI being requested. An authenticated user can connect to their own project-scoped MCP endpoint and supply a crafted file-download URI that points to another user&amp;#39;s flow-backed file. The server then reads and returns the victim file without verifying ownership or project membership.&lt;/p&gt;
&lt;p&gt;This is a cross-user authorization bypass (`userA -&amp;gt; userB`) that allows arbitrary read access to files stored under other users&amp;#39; flow namespaces.&lt;/p&gt;
&lt;p&gt;### Details
Verified against local checkout:&lt;/p&gt;
&lt;p&gt;- Repository: `langflow-ai/langflow`
- Verified on release tag: `v1.8.3`
- Commit: `08bf98404cfd7737fde57a2588785766cdf1b42e`
- Earliest stable release known to contain the vulnerable code path: `v1.6.8`&lt;/p&gt;
&lt;p&gt;Relevant code path:&lt;/p&gt;
&lt;p&gt;1. `src/backend/base/langflow/api/v1/mcp_projects.py:147-193`
   `verify_project_auth_conditional()` authenticates the caller and checks access only to the `project_id` in the MCP transport URL.&lt;/p&gt;
&lt;p&gt;2. `src/backend/base/langflow/api/v1/mcp_projects.py:1238-1241`
   The project-scoped MCP server registers `read_resource()` and forwards the attacker-controlled URI directly to `handle_read_resource(uri=uri)`.&lt;/p&gt;
&lt;p&gt;3. `src/backend/base/langflow/api/v1/mcp_utils.py:163-182`
   `handle_read_resource()` parses the last two URI path segments as `flow_id` and `filename`, then directly calls:&lt;/p&gt;
&lt;p&gt;```pytho…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: langflow&lt;/p&gt;
&lt;p&gt;### Summary
Langflow&amp;#39;s project-scoped MCP transport authenticates the caller for the `project_id` in the connection URL, but the subsequent `resources/read` operation does not authorize the resource URI being requested. An authenticated user can connect to their own project-scoped MCP endpoint and supply a crafted file-download URI that points to another user&amp;#39;s flow-backed file. The server then reads and returns the victim file without verifying ownership or project membership.&lt;/p&gt;
&lt;p&gt;This is a cross-user authorization bypass (`userA -&amp;gt; userB`) that allows arbitrary read access to files stored under other users&amp;#39; flow namespaces.&lt;/p&gt;
&lt;p&gt;### Details
Verified against local checkout:&lt;/p&gt;
&lt;p&gt;- Repository: `langflow-ai/langflow`
- Verified on release tag: `v1.8.3`
- Commit: `08bf98404cfd7737fde57a2588785766cdf1b42e`
- Earliest stable release known to contain the vulnerable code path: `v1.6.8`&lt;/p&gt;
&lt;p&gt;Relevant code path:&lt;/p&gt;
&lt;p&gt;1. `src/backend/base/langflow/api/v1/mcp_projects.py:147-193`
   `verify_project_auth_conditional()` authenticates the caller and checks access only to the `project_id` in the MCP transport URL.&lt;/p&gt;
&lt;p&gt;2. `src/backend/base/langflow/api/v1/mcp_projects.py:1238-1241`
   The project-scoped MCP server registers `read_resource()` and forwards the attacker-controlled URI directly to `handle_read_resource(uri=uri)`.&lt;/p&gt;
&lt;p&gt;3. `src/backend/base/langflow/api/v1/mcp_utils.py:163-182`
   `handle_read_resource()` parses the last two URI path segments as `flow_id` and `filename`, then directly calls:&lt;/p&gt;
&lt;p&gt;```pytho…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4hmc-cfm3-w43c</guid>
    </item>
  </channel>
</rss>
