Python Sdk
Monthly
Unbounded HTTP request-body buffering in the Model Context Protocol Python SDK (the 'mcp' package) before 1.29.1 and in 2.0.0a1 through 2.0.1 allows unauthenticated remote attackers who can reach an exposed HTTP transport endpoint to exhaust server memory and potentially terminate the process. The Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes read complete request bodies without any maximum-size check, so a single large declared or streamed body can consume multiple times its own size in process memory and repeated requests can drive sustained memory pressure. Per the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) the impact is availability-only, and no public exploit code was identified at time of analysis; stdio-only servers and deployments behind an effective upstream request-size limit are not affected. This is a genuine but bounded-priority availability issue - the fix is a vendor-released patch in 1.29.1 and 2.1.0 that enforces a 4 MiB default body cap and returns HTTP 413, and the primary residual exposure is default HTTP deployments with no reverse-proxy or gateway body limit.
Cross-origin WebSocket hijacking in the Model Context Protocol Python SDK (mcp on PyPI) before 1.28.1 lets a remote web page connect to any application exposing the deprecated mcp.server.websocket.websocket_server transport, because that transport accepted handshakes without Host or Origin validation and offered no SDK-level control to restrict connecting origins. A malicious site loaded in a victim's browser can therefore open an MCP session against a locally reachable server and drive its tools. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; the tags flag it as information disclosure.
Missing authorization in the MCP Python SDK (the `mcp` PyPI package) versions 1.23.0 through 1.27.1 lets any authenticated client of a multi-client server enumerate, read the results of, consume messages from, or cancel tasks belonging to other clients. The default handlers wired up by `server.experimental.enable_tasks()` for tasks/list, tasks/get, tasks/result, and tasks/cancel key solely on the task identifier and never bind a task to the session that created it. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the upstream fix, deprecation warnings, and detailed advisory confirm the flaw; it is resolved in version 1.27.2.
Cross-session message injection in the MCP Python SDK (the 'mcp' package on PyPI) prior to 1.27.2 allows an authenticated client holding a valid bearer token to hijack another principal's session on the SSE and stateful Streamable HTTP transports. Because SseServerTransport and StreamableHTTPSessionManager route inbound requests using only the session_id query parameter or Mcp-Session-Id header - never checking that the caller is the same authenticated principal who created the session - any bearer-token-authenticated client who learns a victim's session ID can inject arbitrary JSON-RPC messages into that session. There is no public exploit identified at time of analysis and no CISA KEV listing; the flaw is fixed in version 1.27.2.
Client-side server-side request forgery and denial of service in the official Model Context Protocol Python SDK: when a connected MCP server declares a tool outputSchema containing an $id or an out-of-document $ref/$dynamicRef (http://, https:// or file://), the SDK's ClientSession, ClientSessionGroup and 2.x Client classes resolve that reference with jsonschema's default resolver, so the client fetches the URL or reads the local file from its own network and filesystem position and blocks the asyncio event loop for every session in the process while doing so. Applications using the SDK purely as a server are not affected; the vulnerable code runs only when a client invokes tools on a server the operator does not fully control. Versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 are affected and are fixed in 1.30.0 and 2.2.0 respectively; no public exploit has been identified at time of analysis, the fetched content is never returned to the malicious server (blind SSRF), and the CVSS 6.5 score reflects availability impact (A:H) rather than confidentiality.
Cross-origin redirect handling in the Model Context Protocol Python SDK (published on PyPI as `mcp`) leaks caller-supplied custom credential headers, and on 307/308 responses the request body, to any host a trusted MCP endpoint redirects to. Affected are HTTP client paths using `streamable_http_client`, `streamablehttp_client`, `sse_client`, `ClientSessionGroup` with HTTP server parameters, the OAuth client providers, or the internal `create_mcp_http_client` helper in versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1, where redirect following was enabled by default or by a caller-supplied client with `follow_redirects=True`. Impact is conditional: a lone `Authorization` bearer header is dropped by the HTTP library on cross-origin hops, the body is only re-sent on 307/308, MCP servers and stdio clients are unaffected, and a malicious MCP server gains nothing because it already receives the requests directly, so exploitation depends on an attacker influencing where a trusted endpoint redirects (stale redirect to a lapsed domain, misrouted proxy rule, attacker-influenced redirect logic). No public exploit code or CISA KEV entry was identified at time of analysis, and the vendor-released fix is available in 1.30.0 (1.x) and 2.2.0 (2.x).
Resource-confusion in the Model Context Protocol Python SDK (pip package mcp) causes server-side bearer authentication to accept a token that was issued for a different service. The flaw affects HTTP servers built on the SDK that configure auth=AuthSettings(...) with a token_verifier, and it only bites when the same authorization server issues tokens for multiple resources and the deployment's TokenVerifier does not itself check the token's aud audience; in that setup an attacker who already holds a valid bearer token for another service can present it to the wrong MCP server and exercise the access it carries (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, CWE-863). Affected builds are mcp 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1; single-resource deployments, verifiers that already validate aud, and correctly configured patched versions are not exposed. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; exploitation requires a pre-existing token plus a specific multi-resource authorization-server topology.
Unbounded server-side memory growth in stateful Streamable HTTP servers built on the MCP Python SDK (the 'mcp' package on PyPI) lets any client that can reach the endpoint exhaust process memory and force a restart. Versions 1.8.0 and later on the affected lines - including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager - retain session entries (with their parsed initialize parameters) that are never aged out or capped, so repeated ordinary short requests accumulate indefinitely; the CVSS 4.0 base score of 6.9 reflects availability-only impact, and no public exploit code has been identified at time of analysis. Stateless HTTP, stdio, and SSE transports are not affected, and the issue is fixed in versions 1.30.0 and 2.2.0.
Unbounded HTTP request-body buffering in the Model Context Protocol Python SDK (the 'mcp' package) before 1.29.1 and in 2.0.0a1 through 2.0.1 allows unauthenticated remote attackers who can reach an exposed HTTP transport endpoint to exhaust server memory and potentially terminate the process. The Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes read complete request bodies without any maximum-size check, so a single large declared or streamed body can consume multiple times its own size in process memory and repeated requests can drive sustained memory pressure. Per the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) the impact is availability-only, and no public exploit code was identified at time of analysis; stdio-only servers and deployments behind an effective upstream request-size limit are not affected. This is a genuine but bounded-priority availability issue - the fix is a vendor-released patch in 1.29.1 and 2.1.0 that enforces a 4 MiB default body cap and returns HTTP 413, and the primary residual exposure is default HTTP deployments with no reverse-proxy or gateway body limit.
Cross-origin WebSocket hijacking in the Model Context Protocol Python SDK (mcp on PyPI) before 1.28.1 lets a remote web page connect to any application exposing the deprecated mcp.server.websocket.websocket_server transport, because that transport accepted handshakes without Host or Origin validation and offered no SDK-level control to restrict connecting origins. A malicious site loaded in a victim's browser can therefore open an MCP session against a locally reachable server and drive its tools. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; the tags flag it as information disclosure.
Missing authorization in the MCP Python SDK (the `mcp` PyPI package) versions 1.23.0 through 1.27.1 lets any authenticated client of a multi-client server enumerate, read the results of, consume messages from, or cancel tasks belonging to other clients. The default handlers wired up by `server.experimental.enable_tasks()` for tasks/list, tasks/get, tasks/result, and tasks/cancel key solely on the task identifier and never bind a task to the session that created it. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the upstream fix, deprecation warnings, and detailed advisory confirm the flaw; it is resolved in version 1.27.2.
Cross-session message injection in the MCP Python SDK (the 'mcp' package on PyPI) prior to 1.27.2 allows an authenticated client holding a valid bearer token to hijack another principal's session on the SSE and stateful Streamable HTTP transports. Because SseServerTransport and StreamableHTTPSessionManager route inbound requests using only the session_id query parameter or Mcp-Session-Id header - never checking that the caller is the same authenticated principal who created the session - any bearer-token-authenticated client who learns a victim's session ID can inject arbitrary JSON-RPC messages into that session. There is no public exploit identified at time of analysis and no CISA KEV listing; the flaw is fixed in version 1.27.2.
Client-side server-side request forgery and denial of service in the official Model Context Protocol Python SDK: when a connected MCP server declares a tool outputSchema containing an $id or an out-of-document $ref/$dynamicRef (http://, https:// or file://), the SDK's ClientSession, ClientSessionGroup and 2.x Client classes resolve that reference with jsonschema's default resolver, so the client fetches the URL or reads the local file from its own network and filesystem position and blocks the asyncio event loop for every session in the process while doing so. Applications using the SDK purely as a server are not affected; the vulnerable code runs only when a client invokes tools on a server the operator does not fully control. Versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 are affected and are fixed in 1.30.0 and 2.2.0 respectively; no public exploit has been identified at time of analysis, the fetched content is never returned to the malicious server (blind SSRF), and the CVSS 6.5 score reflects availability impact (A:H) rather than confidentiality.
Cross-origin redirect handling in the Model Context Protocol Python SDK (published on PyPI as `mcp`) leaks caller-supplied custom credential headers, and on 307/308 responses the request body, to any host a trusted MCP endpoint redirects to. Affected are HTTP client paths using `streamable_http_client`, `streamablehttp_client`, `sse_client`, `ClientSessionGroup` with HTTP server parameters, the OAuth client providers, or the internal `create_mcp_http_client` helper in versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1, where redirect following was enabled by default or by a caller-supplied client with `follow_redirects=True`. Impact is conditional: a lone `Authorization` bearer header is dropped by the HTTP library on cross-origin hops, the body is only re-sent on 307/308, MCP servers and stdio clients are unaffected, and a malicious MCP server gains nothing because it already receives the requests directly, so exploitation depends on an attacker influencing where a trusted endpoint redirects (stale redirect to a lapsed domain, misrouted proxy rule, attacker-influenced redirect logic). No public exploit code or CISA KEV entry was identified at time of analysis, and the vendor-released fix is available in 1.30.0 (1.x) and 2.2.0 (2.x).
Resource-confusion in the Model Context Protocol Python SDK (pip package mcp) causes server-side bearer authentication to accept a token that was issued for a different service. The flaw affects HTTP servers built on the SDK that configure auth=AuthSettings(...) with a token_verifier, and it only bites when the same authorization server issues tokens for multiple resources and the deployment's TokenVerifier does not itself check the token's aud audience; in that setup an attacker who already holds a valid bearer token for another service can present it to the wrong MCP server and exercise the access it carries (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, CWE-863). Affected builds are mcp 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1; single-resource deployments, verifiers that already validate aud, and correctly configured patched versions are not exposed. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; exploitation requires a pre-existing token plus a specific multi-resource authorization-server topology.
Unbounded server-side memory growth in stateful Streamable HTTP servers built on the MCP Python SDK (the 'mcp' package on PyPI) lets any client that can reach the endpoint exhaust process memory and force a restart. Versions 1.8.0 and later on the affected lines - including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager - retain session entries (with their parsed initialize parameters) that are never aged out or capped, so repeated ordinary short requests accumulate indefinitely; the CVSS 4.0 base score of 6.9 reflects availability-only impact, and no public exploit code has been identified at time of analysis. Stateless HTTP, stdio, and SSE transports are not affected, and the issue is fixed in versions 1.30.0 and 2.2.0.