CVE-2026-59950: Cross-Site WebSocket Hijacking in Model Context Protocol Python SDK

The Model Context Protocol (MCP) Python SDK before version 1.28.1 provides a WebSocket server transport implementation within the mcp.server.websocket module. This transport is built as an Asynchronous Server Gateway Interface (ASGI) application designed to facilitate JSON-RPC communications between Large Language Model (LLM) platforms and external tools. The service operates locally or within internal network perimeters, managing sensitive actions like local file access, command execution, and developer tool integrations.

The attack surface is exposed because the WebSocket protocol does not adhere to the Same-Origin Policy (SOP). While browsers restrict standard cross-origin HTTP requests, they permit cross-origin WebSocket connection handshakes to any address, including localhost. This fundamental browser behavior requires the WebSocket server itself to actively inspect and validate incoming HTTP upgrade headers.

Prior to version 1.28.1, the SDK's WebSocket server transport completed handshakes without performing validation on either the Origin or Host headers. This architectural oversight exposes environments hosting an MCP server to unauthenticated Cross-Site WebSocket Hijacking (CSWSH) and DNS rebinding attacks. An attacker can leverage this exposure to interact with internal models and execute sensitive tool actions.

The root cause of the vulnerability lies in the implementation of the websocket_server coroutine within src/mcp/server/websocket.py. The transport was designed to handle incoming ASGI connections by immediately instantiating a Starlette-compatible WebSocket interface and executing the connection upgrade sequence.

In the vulnerable implementation, the server calls the websocket.accept() method directly upon receipt of a connection request. It does not perform any structural validation on the headers supplied within the ASGI scope. Under the Starlette ASGI framework, calling accept sends an websocket.accept event back to the server, which completes the HTTP 101 Switching Protocols handshake.

Because the Same-Origin Policy is not enforced by browsers for WebSocket handshakes, any website loaded within the victim's browser can trigger this upgrade handshake. In the absence of an explicit validation step that checks the Origin header against an approved list of origins, the server establishes a persistent, bi-directional communication channel with the third-party client. Additionally, the lack of Host header verification allows attackers to route connections via a malicious domain pointing to 127.0.0.1, bypassing DNS-based restrictions.

The patch in commit 777b8d06710c140e3606b0d4598e2aa48546c266 resolves the vulnerability by decoupling the transport security validation from Starlette's high-level Request object and integrating it into the low-level ASGI WebSocket lifecycle.

In src/mcp/server/transport_security.py, the TransportSecurityMiddleware was modified to accept HTTPConnection instead of Request. This modification allows the validation engine to parse both standard HTTP requests and ASGI WebSocket connection scopes.

# src/mcp/server/transport_security.py
-from starlette.requests import Request
+from starlette.requests import HTTPConnection
...
-    async def validate_request(self, request: Request, is_post: bool = False) -> Response | None:
+    async def validate_request(self, request: HTTPConnection, is_post: bool = False) -> Response | None:

In src/mcp/server/websocket.py, the websocket_server coroutine was updated to instantiate this middleware and run validations before invoking websocket.accept().

# src/mcp/server/websocket.py
     websocket = WebSocket(scope, receive, send)
+
+    security = TransportSecurityMiddleware(security_settings)
+    error_response = await security.validate_request(websocket, is_post=False)
+    if error_response is not None:
+        # Terminating the socket before accepting triggers a 403 Forbidden
+        await websocket.close()
+        raise ValueError("Request validation failed")
+
     await websocket.accept(subprotocol="mcp")

If validation fails, the server invokes websocket.close() prior to initiating the handshake acceptance. According to the ASGI specification, closing an unaccepted WebSocket connection maps to an HTTP 403 response, preventing the establishment of the session.

To execute a Cross-Site WebSocket Hijacking (CSWSH) attack against the vulnerable MCP transport, several prerequisites must be met. The victim must be running an application built on the vulnerable MCP SDK that exposes the websocket_server transport on a predictable local port. Concurrently, the victim must navigate to an attacker-controlled web page in a browser session.

The attack flow is represented in the diagram below:

When the victim loads the malicious page, a client-side JavaScript payload initiates a connection attempt using the standard browser WebSocket API. Since the browser includes the original Origin: http://evil.com header, the server should reject it, but the vulnerable SDK accepts it. Once the connection is open, the attacker can execute arbitrary JSON-RPC methods, such as listing files or executing local tools on behalf of the user.

The security impact of CVE-2026-59950 is classified as high, carrying a CVSS v4.0 base score of 7.6. The primary consequences involve a complete loss of confidentiality and integrity of the local environment hosting the MCP server. An attacker operating through a hijacked browser connection can issue arbitrary JSON-RPC command payloads to the server.

Because MCP servers frequently interface directly with local file systems, databases, and development tools, the attacker can exploit active tools to execute host system commands, read sensitive files, or exfiltrate configuration credentials. Since the attack is executed through the victim's browser session, the server processes the commands with the full execution permissions of the local user running the SDK application.

This vulnerability is particularly severe for developers using LLM integrations, as local environments are typically trusted and rarely isolated by application-level authentication. No active exploitation has been reported in the wild, and the vulnerability is not currently listed in the CISA KEV catalog.

Remediation requires upgrading the mcp PyPI dependency to version 1.28.1 or higher. However, updating the package alone is insufficient to secure existing applications. Because the newly introduced validation checks are designed as opt-in configurations, developers must explicitly pass a populated TransportSecuritySettings configuration to the server.

To configure origin and host validation, instantiate the security settings with your trusted environments and pass it during transport initialization:

from mcp.server.transport_security import TransportSecuritySettings
from mcp.server.websocket import websocket_server
 
security_settings = TransportSecuritySettings(
    enable_dns_rebinding_protection=True,
    allowed_hosts=["127.0.0.1:*", "localhost:*"],
    allowed_origins=["http://localhost:*", "http://127.0.0.1:*"]
)
 
# Implement in the ASGI application context:
async with websocket_server(
    scope, receive, send, security_settings=security_settings
) as streams:
    ...

Additionally, because the WebSocket server transport in the MCP Python SDK is deprecated and entirely removed in version 2.0, organizations should actively migrate their applications to supported alternatives. Valid alternatives include the standard input/output (stdio) transport or the Streamable HTTP (SSE) transport pattern, both of which are officially maintained.