Three high-severity CVEs in the official Model Context Protocol Python SDK describe separate failures at client and origin boundaries. CVE-2026-52869 concerns authenticated HTTP sessions, CVE-2026-52870 concerns opt-in experimental tasks, and CVE-2026-59950 concerns the deprecated WebSocket transport.
These are vulnerability reports, not incident reports. The reviewed records do not report exploitation in the wild, and MCPwatch did not reproduce the behaviors. Each issue has narrow prerequisites, so package-version presence alone does not establish exposure.
What the three records establish
The CVE-2026-52869 record and repository advisory assign a high 7.1 CVSS 3.1 score and CWE-639. The affected pip package is mcp through 1.27.1, with 1.27.2 identified as the first patched version.
The CVE-2026-52870 record and repository advisory assign a high 7.6 CVSS 3.1 score and CWE-862. They cover versions 1.23.0 through 1.27.1; 1.27.2 is the first patched version.
The CVE-2026-59950 record and repository advisory assign a high 7.6 CVSS 4.0 score, with CWE-346 and CWE-1385. The listed package range is before 1.28.1, but the transport-specific and configuration-specific conditions below determine practical exposure.
CVE-2026-52869: authenticated session ownership
The SDK advisory says stateful SSE and Streamable HTTP transports selected an existing session by its identifier without confirming that the authenticated principal matched the principal that created it. A different authenticated client that obtained a session identifier could therefore submit messages into that session. For Streamable HTTP, the advisory says that client could also receive the result.
This does not make every HTTP deployment vulnerable. The official scope requires an HTTP transport with state, authentication enabled, and a session identifier obtained outside its normal context. Stdio, stateless Streamable HTTP, and servers without an authentication boundary are outside this CVE’s stated scope. Random UUID session IDs increase attack complexity but should not be treated as authorization credentials.
Exposure review should therefore examine where session identifiers appear: reverse-proxy access logs, application traces, browser tooling, support bundles, and distributed tracing systems can all broaden who can see them. That review should avoid copying active identifiers into new tickets. The patched principal comparison is the authorization control; reducing identifier leakage is useful defense in depth, not a substitute for upgrading.
CVE-2026-52870: experimental task ownership
The second advisory concerns servers that explicitly call server.experimental.enable_tasks(). The default handlers did not associate task operations with the session that created a task. On a multi-client server, another connected client could list tasks, read status or results, consume queued task messages, or cancel a task.
The feature is experimental and opt-in. Applications that do not enable it are not affected according to the vendor. Custom task handlers require a separate code review: they are not automatically vulnerable, but they must enforce equivalent ownership checks.
CVE-2026-59950: deprecated WebSocket origin checks
The WebSocket advisory covers mcp.server.websocket.websocket_server, a deprecated transport that was never part of the MCP specification and is not exposed through FastMCP. The vendor says it accepted connections without SDK-level Host or Origin validation. A browser page could therefore connect to a reachable server lacking separate authentication or an origin gate.
Upgrading to 1.28.1 adds an optional transport-security setting, but the advisory explicitly says validation remains disabled unless the application supplies appropriate security settings. Upgrade-only remediation is therefore incomplete for deployments that continue using this transport. The vendor’s preferred path is migration to Streamable HTTP; the WebSocket transport is removed in version 2.
Operators should also identify controls outside the SDK. An authenticating reverse proxy, explicit origin enforcement, and network segmentation may change reachability, but only if every route to the application passes through those controls. A localhost bind narrows network exposure yet can still be reachable from a browser context under the conditions described by the advisory.
Patch boundaries and configuration work
MCPwatch verified the repository releases for v1.27.2 and v1.28.1. Version 1.27.2 addresses the two session-ownership issues. Version 1.28.1 is the latest verified release and includes the WebSocket change.
Operators should inventory the runtime package version and transport mode together. A lockfile does not prove that all live processes restarted, while a patched package does not prove that optional origin validation was configured. Hosted clients and gateways that multiplex users through one OAuth client should also ensure the token verifier supplies a subject identity, as the session advisory recommends.
Defensive review checklist
- Confirm the live SDK build. Capture the package version from each running environment and reconcile replicas.
- Classify transports. Record stdio, SSE, stateful or stateless Streamable HTTP, and any direct WebSocket use.
- Review authentication identity. For stateful HTTP, verify that client, issuer, and subject claims establish the intended session boundary.
- Search for experimental tasks. Identify calls that enable tasks and review custom handlers for per-session ownership.
- Remove deprecated WebSocket use where possible. Otherwise configure allowed hosts and origins after upgrading, and test rejection paths defensively.
- Protect session identifiers. Avoid logging them unnecessarily and restrict access to traces that contain them.
- Do not infer an incident from a match. Escalate only when runtime evidence, logs, or cross-client behavior supports it.
Scope and uncertainty
MCPwatch verified the CVE records, GitHub advisories, package ranges, severity data, repository commits referenced by the advisories, and release tags. It did not test a live SDK deployment or independently reproduce cross-client access. Consequences depend on application tools, resources, authentication design, transport exposure, and whether experimental features are enabled.