MCP Python SDK EUVD-2026-111366

The application must use the SDK as an MCP client - ClientSession over any transport, ClientSessionGroup, or the 2.x Client class - and must call tools on an MCP server the operator does not fully control; server-only applications are not affected. The malicious server must declare a tool outputSchema containing an $id or an out-of-document $ref/$dynamicRef (one not starting with '#') that uses an http://, https:// or file:// scheme. There is no configuration setting that disables this validation, so no non-default option is required on the victim side; the primary limiting factor is that exploitation depends entirely on the client connecting to and invoking tools on an untrusted/compromised server. The blind nature (fetched content is never returned to the server) limits confidentiality impact; the main realistic impact is the event-loop stall affecting all sessions in the process.

This is a medium-severity, client-side flaw (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) in the official Model Context Protocol Python SDK, classified as CWE-918 (SSRF). The signals point to a real but bounded priority. The vuln.today decision label is 'this_month' (not act_now/emergency), it is NOT on CISA KEV, no EPSS score was supplied, and no public exploit was identified - only vendor advisory, PRs and patch commits. The CVSS impact set (C:N/I:N/A:H) is internally consistent and worth highlighting: although a malicious server can make the client read local files and issue internal HTTP(S) requests, the GHSA states the fetched content is used only as a schema and never returned to the server, so confidentiality/integrity impact is scored None and the dominant impact is availability - the synchronous, timeout-less fetch freezes every session in the process. Note two things defenders should verify: (1) CWE-918/SSRF and file:// reads normally imply confidentiality exposure, yet the official vector sets C:N precisely because the read data is not exfiltrated back to the attacker - the SSRF is blind, which lowers real-world severity versus a typical SSRF; (2) exploitation is gated on the victim acting as an MCP client that calls tools on an untrusted server, so this is not an internet-exposed service flaw. Overall: patch within a normal cycle, prioritize if your deployment connects MCP clients to third-party/untrusted servers.

An attacker operates (or compromises) an MCP server that a victim's client connects to. When the client calls one of the server's tools, the server returns a tool whose declared outputSchema contains a $ref pointing to an attacker-chosen http://, https:// or file:// URL; the client's jsonschema default resolver fetches it, producing a blind internal request or local-file read from the client's network/filesystem position, and - because resolution runs synchronously with no timeout - a server that accepts the connection then stalls will freeze every session in the client process. No public exploit was identified at time of analysis; the attack requires the client to call tools on a server the operator does not fully control (AV:N/AC:L, but UI:R reflecting that the client must actively invoke the tool).