The defect concerns who owns a piece of asynchronous work after its initial request has finished. A task can outlive the connection on which it was created and can retain results, status and messages. A server that checks only whether the caller knows the task identifier has not necessarily checked whether that caller is allowed to use the task. ## The…
Inspect the ClaimsCase · DiggingBeagle record
MCP Python SDK tasks crossed client-session boundaries
The MCP Python SDK’s experimental task handlers let one connected client read or cancel another client’s work. Version 1.27.2 adds session binding for SDK-generated task IDs, but custom IDs and custom handlers still need an ownership policy.
Scope
CVE-2026-52870 applies only to applications that enabled the low-level experimental tasks feature. It does not describe every MCP Python SDK deployment.
Assessment profile
Assessment method- Exploitation
- not established
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
Maintainer advisory checked on 1 October 2026. The assessment distinguishes default handlers and SDK-generated IDs from custom storage/handler paths; no deployment-specific exploit or live victim impact was independently tested.
Assessed Oct 1, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-CROSS · CLM-PATCH · CLM-AFFECTED · CLM-CUSTOM-ID-LIMIT · MCP Python SDK experimental task handlers allowed cross-client task access · MCP 2025-11-25: task isolation and access control
At a glance
## Protocol context The MCP task specification requires authenticated tasks to be bound to their authorization context and restricts the corresponding operations. This is stronger than treating an opaque identifier as a universal credential. Review the protocol version and the actual server implementation together; the specification is not proof that a…
Read the implicationsThe public advisory does not establish exploitation in the wild.
Limits and uncertaintyFull account
The defect concerns who owns a piece of asynchronous work after its initial request has finished. A task can outlive the connection on which it was created and can retain results, status and messages. A server that checks only whether the caller knows the task identifier has not necessarily checked whether that caller is allowed to use the task.
The exposed operations
The advisory covers the default handlers installed by server.experimental.enable_tasks(). A connected client could enumerate tasks, inspect their status and results, and cancel work created by another client. Enumeration matters because it removes the need to discover an identifier through a separate leak. Retrieving queued elicitation messages could also consume material intended for the original client, so the issue affected workflow integrity as well as confidentiality.
Conditions and remediation boundary
The affected range is 1.23.0 through 1.27.1, and the feature had to be enabled. Applications that did not enable experimental tasks are outside this advisory. The listed patch is 1.27.2, but its automatic protection follows the SDK-generated task-ID path. Applications supplying their own IDs or manipulating the store directly must retain a separate ownership check; a custom handler is not secured merely because the default handler was changed.
Why asynchronous agents make the boundary important
The same design question appears in batch inference, approval queues and long-running tool operations: which principal may list, fetch, cancel or consume each object? A successful initial connection should not silently confer authority over everything in a shared store. Ownership needs to be represented where the object is created and enforced where it is later used, including error, cancellation and notification paths.
Evidence and limits
The maintainer advisory is the basis for the affected-version and repair statements. This review did not run a multi-client exploit or test a deployment. The public evidence does not establish exploitation in the wild or a count of exposed customers. Potential consequences depend on the sensitivity of task results and on what a task is authorized to do.
Mechanism and trust boundary
- 01
Client creates a task
Experimental tasks create a long-lived task identifier.
Boundary: client / task store
- 02
Server stores the task without creator-session ownership
Affected handlers can later resolve the task by identifier alone.
Boundary: task identity / authorization
- 03
Another client uses task operations
A different connected client can list, read results from or cancel the task.
Boundary: session A / session B
Timeline
- Jun 5, 2026Event type unspecified
GitHub advisory published
The MCP Python SDK advisory documents the experimental-task authorization flaw.
- Jul 16, 2026Event type unspecified
Advisory metadata updated
The reviewed advisory record was updated in July.
Claims & evidence
CLM-CROSSThe default experimental task handlers did not bind a task to the session that created it, so another connected client could observe, read results from or cancel that task.supported
Basis: reported finding · active
- supportsMCP Python SDK experimental task handlers allowed cross-client task accessprimary disclosure
Summary and details
CLM-PATCHThe MCP Python SDK advisory lists version 1.27.2 as the patched version for CVE-2026-52870.supported
Basis: reported finding · active
- supportsMCP Python SDK experimental task handlers allowed cross-client task accessprimary disclosure
Patched versions
CLM-AFFECTEDCVE-2026-52870 affected MCP Python SDK versions 1.23.0 through 1.27.1 when applications explicitly enabled the experimental tasks feature.supported
Basis: reported finding · active
- supportsMCP Python SDK experimental task handlers allowed cross-client task accessprimary disclosure
Affected versions and Am I affected?
CLM-CUSTOM-ID-LIMITThe advisory says the patch binds SDK-generated run_task IDs to the creating session; explicit task IDs and direct TaskStore writes do not receive that automatic binding and remain reachable by ID.supported
Basis: reported finding
Material revision: Oct 1, 2026
- supportsMCP Python SDK experimental task handlers allowed cross-client task accessprimary disclosure
Remediation: explicit task_id, direct TaskStore writes and custom handlers
Evidence visuals
diagram
MCP task ownership gap
- Client A
Creates an experimental task
- Task store
Task ID stored without creator-session ownership check
- Client B
Uses list/get/result/cancel against another client's task
- Client A Task store: create task
- Client B Task store: cross-client operations
Implications
Protocol context
The MCP task specification requires authenticated tasks to be bound to their authorization context and restricts the corresponding operations. This is stronger than treating an opaque identifier as a universal credential. Review the protocol version and the actual server implementation together; the specification is not proof that a particular implementation enforced it.
Comparison and conclusion
Cross-session authorization is an object-ownership problem, whereas the WebSocket advisory begins with admission of a browser connection. A system can fix either layer and still fail the other. The escalation scenario is conditional: if increasingly valuable agent tasks share an owner-blind store, a single permitted client gains leverage over other users’ work. The remedy is to constrain the object operation, not simply strengthen the initial login.
Controls and mitigations
- Maintainer remediation: update affected uses of the experimental task handlers to 1.27.2 or an appropriate supported version, then review explicit task IDs, direct store writes and custom handlers separately.
- DiggingBeagle test recommendation: create work under principal A, then verify that principal B cannot list it, fetch its result, consume its messages or cancel it, including after reconnection.
- Keep the authorization principal distinct from a transport/session identifier where the application permits reconnection or credential changes; document the mapping and test its lifecycle.
Unknowns and contradictions
- The public advisory does not establish exploitation in the wild.
Sources and citation
Material revision history
- Sep 16, 2026 · Published version · first publication · revision 2
- Oct 1, 2026 · Published version · material revision · revision 65Public fields changed: assessment_profile, claims, implications, mitigations, narrative, references, summary