https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 22:52:59 +0000 https://cve.radiocsirt.org/vuln/cve-2026-52870 <p><strong>Affected:</strong> modelcontextprotocol python-sdk</p> <p>The MCP Python SDK, called mcp on PyPI, is a Python implementation of the Model Context Protocol (MCP). From 1.23.0 until 1.27.2, default handlers installed by server.experimental.enable_tasks() for tasks/list, tasks/get, tasks/result, and tasks/cancel operate only on task identifiers without recording the session that created each task, allowing any connected client to enumerate, read results from, consume messages for, or cancel other clients&#39; tasks. This issue is fixed in version 1.27.2.</p> <p><strong>Affected:</strong> modelcontextprotocol python-sdk</p> <p>The MCP Python SDK, called mcp on PyPI, is a Python implementation of the Model Context Protocol (MCP). From 1.23.0 until 1.27.2, default handlers installed by server.experimental.enable_tasks() for tasks/list, tasks/get, tasks/result, and tasks/cancel operate only on task identifiers without recording the session that created each task, allowing any connected client to enumerate, read results from, consume messages for, or cancel other clients&#39; tasks. This issue is fixed in version 1.27.2.</p> https://cve.radiocsirt.org/vuln/cve-2026-52870 https://cve.radiocsirt.org/vuln/ghsa-hvrp-rf83-w775 <p><strong>Affected:</strong> PyPI: mcp</p> <p>### Summary In affected versions, the default request handlers installed by the experimental tasks feature (`server.experimental.enable_tasks()`) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients.</p> <p>### Am I affected? Only if the developer&#39;s application server calls `server.experimental.enable_tasks()`. If `grep -r enable_tasks` over their codebase finds nothing, the application is not affected.</p> <p>### Details When tasks support is enabled on the low-level server, default handlers are registered for `tasks/list`, `tasks/get`, `tasks/result`, and `tasks/cancel`. These handlers operated on the task identifier alone and kept no record of the session that created each task. Because `tasks/list` returned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task&#39;s status and result via `tasks/get` and `tasks/result`, retrieve queued task messages — such as elicitation requests intended for the task&#39;s creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task via `tasks/cancel`.</p> <p>### Impact Servers that call `server.experimental.enable_tasks()` and serve multiple clients are affected: one client can read other clients&#39; task results and elicitation payloads, consume messages meant for them, and c…</p> <p><strong>Affected:</strong> PyPI: mcp</p> <p>### Summary In affected versions, the default request handlers installed by the experimental tasks feature (`server.experimental.enable_tasks()`) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients.</p> <p>### Am I affected? Only if the developer&#39;s application server calls `server.experimental.enable_tasks()`. If `grep -r enable_tasks` over their codebase finds nothing, the application is not affected.</p> <p>### Details When tasks support is enabled on the low-level server, default handlers are registered for `tasks/list`, `tasks/get`, `tasks/result`, and `tasks/cancel`. These handlers operated on the task identifier alone and kept no record of the session that created each task. Because `tasks/list` returned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task&#39;s status and result via `tasks/get` and `tasks/result`, retrieve queued task messages — such as elicitation requests intended for the task&#39;s creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task via `tasks/cancel`.</p> <p>### Impact Servers that call `server.experimental.enable_tasks()` and serve multiple clients are affected: one client can read other clients&#39; task results and elicitation payloads, consume messages meant for them, and c…</p> https://cve.radiocsirt.org/vuln/ghsa-hvrp-rf83-w775 https://cve.radiocsirt.org/vuln/pysec-2026-3481 <p><strong>Affected:</strong> PyPI: mcp</p> <p>### Summary In affected versions, the default request handlers installed by the experimental tasks feature (`server.experimental.enable_tasks()`) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients.</p> <p>### Am I affected? Only if the developer&#39;s application server calls `server.experimental.enable_tasks()`. If `grep -r enable_tasks` over their codebase finds nothing, the application is not affected.</p> <p>### Details When tasks support is enabled on the low-level server, default handlers are registered for `tasks/list`, `tasks/get`, `tasks/result`, and `tasks/cancel`. These handlers operated on the task identifier alone and kept no record of the session that created each task. Because `tasks/list` returned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task&#39;s status and result via `tasks/get` and `tasks/result`, retrieve queued task messages — such as elicitation requests intended for the task&#39;s creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task via `tasks/cancel`.</p> <p>### Impact Servers that call `server.experimental.enable_tasks()` and serve multiple clients are affected: one client can read other clients&#39; task results and elicitation payloads, consume messages meant for them, and c…</p> <p><strong>Affected:</strong> PyPI: mcp</p> <p>### Summary In affected versions, the default request handlers installed by the experimental tasks feature (`server.experimental.enable_tasks()`) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients.</p> <p>### Am I affected? Only if the developer&#39;s application server calls `server.experimental.enable_tasks()`. If `grep -r enable_tasks` over their codebase finds nothing, the application is not affected.</p> <p>### Details When tasks support is enabled on the low-level server, default handlers are registered for `tasks/list`, `tasks/get`, `tasks/result`, and `tasks/cancel`. These handlers operated on the task identifier alone and kept no record of the session that created each task. Because `tasks/list` returned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task&#39;s status and result via `tasks/get` and `tasks/result`, retrieve queued task messages — such as elicitation requests intended for the task&#39;s creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task via `tasks/cancel`.</p> <p>### Impact Servers that call `server.experimental.enable_tasks()` and serve multiple clients are affected: one client can read other clients&#39; task results and elicitation payloads, consume messages meant for them, and c…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3481