MCP Python SDK CVE-2026-59950

Exploitation requires that the target application expose the deprecated mcp.server.websocket.websocket_server transport from mcp < 1.28.1 (applications using only SSE or Streamable HTTP transports are not affected). The attacker cannot connect directly server-to-server in the general case: the CVSS UI:P/AT:P metrics indicate a victim must load attacker-controlled content in a browser that then performs a cross-origin (and/or DNS-rebinding) WebSocket handshake to the MCP endpoint, which the server accepts with no Host or Origin validation. Limiting factors: only the deprecated WebSocket transport is vulnerable; the MCP server must be network-reachable from the victim's browser (commonly a localhost/loopback binding); user interaction (visiting the malicious page) is required; and even after patching, protection is only active if the operator passes TransportSecuritySettings, since the default remains permissive for backward compatibility.

The supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N, score 7.6) captures the shape of this well: network reachable and unauthenticated (PR:N), but gated by an attack requirement (AT:P) and passive user interaction (UI:P) - i.e., a victim must load attacker content in a browser, and the target must run the specific deprecated transport. High confidentiality and integrity impact (VC:H/VI:H) reflect that a hijacked MCP session can read and invoke tools. This is not a wormable, drive-by unauthenticated RCE despite the network vector; the AT:P and UI:P conditions meaningfully constrain it. No EPSS score, no KEV listing, and no POC were provided, so real-world exploitation pressure appears low-to-moderate and opportunistic rather than mass-scale. Note a scope nuance: the practical impact lands on the application's own MCP tools rather than the SDK's process privileges, so downstream severity depends heavily on what tools the exposed server offers. Prioritize based on whether you actually use the deprecated WebSocket transport - most deployments on SSE/Streamable HTTP are unaffected.

A developer runs an MCP-enabled application that exposes the deprecated websocket_server transport on localhost. The developer visits an attacker-controlled web page, whose JavaScript opens a cross-origin WebSocket to ws://127.0.0.1:<port>/ws with subprotocol 'mcp'; because no Origin check is applied, the handshake succeeds and the page drives MCP tool calls to read data or trigger actions. No POC was provided, and the passive user interaction plus DNS-rebinding-style attack requirement (UI:P/AT:P) mean the attacker must lure the victim's browser rather than hit the server directly.