https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 09:33:14 +0000 https://cve.radiocsirt.org/vuln/cve-2026-33760 <p><strong>Affected:</strong> langflow-ai langflow</p> <p>Langflow is a tool for building and deploying AI-powered agents and workflows. Prior to 1.9.0, Langflow&#39;s /api/v1/monitor router exposes 7 endpoints that perform read, write, and delete operations on user-owned resources — messages, sessions, build artifacts, and LLM transaction logs — without verifying that the authenticated requester owns the targeted resource. Any authenticated user can read, modify, rename, or permanently delete another user&#39;s data by supplying the target&#39;s resource ID or flow_id. This is a classic IDOR/BOLA vulnerability. Notably, the same source file (monitor.py) contains one correctly-implemented endpoint that uses an ownership check, demonstrating the correct pattern was known but inconsistently applied. This vulnerability is fixed in 1.9.0.</p> <p><strong>Affected:</strong> langflow-ai langflow</p> <p>Langflow is a tool for building and deploying AI-powered agents and workflows. Prior to 1.9.0, Langflow&#39;s /api/v1/monitor router exposes 7 endpoints that perform read, write, and delete operations on user-owned resources — messages, sessions, build artifacts, and LLM transaction logs — without verifying that the authenticated requester owns the targeted resource. Any authenticated user can read, modify, rename, or permanently delete another user&#39;s data by supplying the target&#39;s resource ID or flow_id. This is a classic IDOR/BOLA vulnerability. Notably, the same source file (monitor.py) contains one correctly-implemented endpoint that uses an ownership check, demonstrating the correct pattern was known but inconsistently applied. This vulnerability is fixed in 1.9.0.</p> https://cve.radiocsirt.org/vuln/cve-2026-33760 https://cve.radiocsirt.org/vuln/ghsa-9c59-2mvc-vfr8 <p><strong>Affected:</strong> PyPI: langflow</p> <p>### Summary</p> <p>Langflow&#39;s `/api/v1/monitor` router exposes 7 endpoints that perform read, write, and delete operations on user-owned resources — messages, sessions, build artifacts, and LLM transaction logs — without verifying that the authenticated requester owns the targeted resource. Any authenticated user can read, modify, rename, or permanently delete another user&#39;s data by supplying the target&#39;s resource ID or `flow_id`. This is a classic IDOR/BOLA vulnerability. Notably, the same source file (`monitor.py`) contains one correctly-implemented endpoint that uses an ownership check, demonstrating the correct pattern was known but inconsistently applied.</p> <p>### Details</p> <p>**Source file: `src/backend/base/langflow/api/v1/monitor.py`**</p> <p>The correct pattern (used only in `GET /monitor/messages`, lines 77–80): ```python stmt = select(MessageTable) stmt = stmt.join(Flow, MessageTable.flow_id == Flow.id) stmt = stmt.where(Flow.user_id == current_user.id) # ownership enforced ```</p> <p>All 7 vulnerable endpoints are missing this guard:</p> <p>**1. `GET /api/v1/monitor/builds` (lines 27–33)** — reads build data for any `flow_id`: ```python @router.get(&#34;/builds&#34;, dependencies=[Depends(get_current_active_user)]) async def get_vertex_builds(flow_id: Annotated[UUID, Query()], session: DbSession): vertex_builds = await get_vertex_builds_by_flow_id(session, flow_id) # no ownership check return VertexBuildMapModel.from_list_of_dicts(vertex_builds) ```</p> <p>**2. `DELETE /api/v1/monitor/messages` (l…</p> <p><strong>Affected:</strong> PyPI: langflow</p> <p>### Summary</p> <p>Langflow&#39;s `/api/v1/monitor` router exposes 7 endpoints that perform read, write, and delete operations on user-owned resources — messages, sessions, build artifacts, and LLM transaction logs — without verifying that the authenticated requester owns the targeted resource. Any authenticated user can read, modify, rename, or permanently delete another user&#39;s data by supplying the target&#39;s resource ID or `flow_id`. This is a classic IDOR/BOLA vulnerability. Notably, the same source file (`monitor.py`) contains one correctly-implemented endpoint that uses an ownership check, demonstrating the correct pattern was known but inconsistently applied.</p> <p>### Details</p> <p>**Source file: `src/backend/base/langflow/api/v1/monitor.py`**</p> <p>The correct pattern (used only in `GET /monitor/messages`, lines 77–80): ```python stmt = select(MessageTable) stmt = stmt.join(Flow, MessageTable.flow_id == Flow.id) stmt = stmt.where(Flow.user_id == current_user.id) # ownership enforced ```</p> <p>All 7 vulnerable endpoints are missing this guard:</p> <p>**1. `GET /api/v1/monitor/builds` (lines 27–33)** — reads build data for any `flow_id`: ```python @router.get(&#34;/builds&#34;, dependencies=[Depends(get_current_active_user)]) async def get_vertex_builds(flow_id: Annotated[UUID, Query()], session: DbSession): vertex_builds = await get_vertex_builds_by_flow_id(session, flow_id) # no ownership check return VertexBuildMapModel.from_list_of_dicts(vertex_builds) ```</p> <p>**2. `DELETE /api/v1/monitor/messages` (l…</p> https://cve.radiocsirt.org/vuln/ghsa-9c59-2mvc-vfr8