Summary
MCP Python SDK: Experimental task handlers allow any client to access and cancel other clients' tasks
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.
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.
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.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
CVE-2026-52870 has a CVSS score of 7.6 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.27.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-52870? CVE-2026-52870 is a high-severity missing authorization vulnerability in mcp (pip), affecting versions >= 1.23.0, <= 1.27.1. It is fixed in 1.27.2. The application does not perform an authorization check before performing a sensitive operation.
- How severe is CVE-2026-52870? CVE-2026-52870 has a CVSS score of 7.6 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of mcp are affected by CVE-2026-52870? mcp (pip) versions >= 1.23.0, <= 1.27.1 is affected.
- Is there a fix for CVE-2026-52870? Yes. CVE-2026-52870 is fixed in 1.27.2. Upgrade to this version or later.
- Is CVE-2026-52870 exploitable, and should I be worried? Whether CVE-2026-52870 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-52870 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-52870? Upgrade
mcpto 1.27.2 or later.