MCP Python SDK: Experimental task handlers allow any client to access and cancel other clients' tasks

### 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. ### Am I affected? Only if the developer's application server calls `server.experimental.enable_tasks()`. If `grep -r enable_tasks` over their codebase finds nothing, the application is not affected. ### 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's status and result via `tasks/get` and `tasks/result`, retrieve queued task messages — such as elicitation requests intended for the task's creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task via `tasks/cancel`. ### Impact Servers that call `server.experimental.enable_tasks()` and serve multiple clients are affected: one client can read other clients' task results and elicitation payloads, consume messages meant for them, and cancel their tasks. The feature is experimental and opt-in, so servers that never enable it are unaffected. Servers that registered their own task handlers instead of the defaults are affected only if those handlers have the same omission. ### Mitigation Upgrade to version 1.27.2 or later, in which task IDs generated by `run_task()` embed an opaque per-session marker and the default handlers restrict each session to its own tasks: requests for another session's task receive "task not found", and `tasks/list` returns only the requesting session's tasks. Tasks created with explicitly chosen IDs or written directly through a `TaskStore` remain reachable by ID but are not listed. Alternatively, leave the experimental tasks feature disabled, or register task handlers that validate session ownership. Source Code Location: https://github.com/modelcontextprotocol/python-sdk Affected Packages: - pip:mcp, affected >= 1.23.0, <= 1.27.1, patched in 1.27.2 CWEs: - CWE-862: Missing Authorization CVSS: - Primary: score 7.6, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L - CVSS_V3: score 7.6, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L References: - https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-hvrp-rf83-w775 - https://nvd.nist.gov/vuln/detail/CVE-2026-52870 - https://github.com/modelcontextprotocol/python-sdk/pull/2720 - https://github.com/modelcontextprotocol/python-sdk/commit/62137874ff26dd74d2fea80ff528a7fd9ca7a5e7 - https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.27.2 - https://github.com/advisories/GHSA-hvrp-rf83-w775