CVE-2026-59951: MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion
Summary In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:
- sessions did not expire; - a client DELETE ended the session but left its entry registered; - a session whose first request was refused stayed registered with a running task.
Each session also kept its parsed initialize parameters, and the number of sessions was unlimited. A client that could reach the endpoint could grow server memory without bound using ordinary short requests; only a restart reclaimed it.
Am I affected? Yes, if you serve MCP over Streamable HTTP in stateful mode and clients you do not fully trust can reach the endpoint. Stateful mode is the default for:
- FastMCP (1.x) - MCPServer and Server.streamablehttpapp() (2.x) - StreamableHTTPSessionManager
Affected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.
Not affected:
- servers on 1.12.0 or later passing statelesshttp=True (no sessions are kept) - servers using only the stdio or SSE transports
Authentication limits who can open sessions, not how many a token holder can open.
Fix Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:
- a session with no request in flight for sessionidletimeout seconds (default 1800) is closed and its ID then answers 404; open streams and in-progress requests keep it alive; - at most maxsessions sessions exist at once (default 10000); a request that would open another is answered 503; - a session is discarded as soon as it ends, whether by DELETE, expiry, or a refused opening request.
Both settings are keyword arguments on FastMCP(...) (1.x), MCPServer.run() / streamablehttpapp() (2.x) and StreamableHTTPSessionManager; None disables them.
This bounds retention rather than eliminating it: a live session still holds its initialize parameters (up to roughly twice the 4 MiB body limit), and an initialize with invalid parameters still opens a session that expires like any other. On a small host, lower sessionidletimeout, maxsessions and maxrequestbodysize to fit.
If you cannot upgrade yet, pass statelesshttp=True (1.12.0 or later) where you need no per-session state, or restrict who can reach the endpoint.
Other sources
The MCP Python SDK, called mcp on PyPI, is a Python implementation of the Model Context Protocol (MCP). From 1.8.0 until 1.30.0 and 2.2.0, stateful Streamable HTTP servers, including FastMCP, MCPServer, Server.streamablehttpapp(), and StreamableHTTPSessionManager, retain session entries without an idle expiration or aggregate session-count limit. DELETE, refused opening requests, and completed sessions do not reliably discard their entries, and each entry can retain parsed initialize parameters. A client that can reach the endpoint can therefore create ordinary short requests that grow server memory without bound until restart. Stateless HTTP, stdio, and SSE transports are not affected. This issue is fixed in versions 1.30.0 and 2.2.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/mcpto a version that resolves this vulnerability.Fixed in 2.2.0 - Upgrade
Upgrade
pip/mcpto a version that resolves this vulnerability.Fixed in 1.30.0 - Upgrade
Upgrade
mcpto a version that resolves this vulnerability.Fixed in 1.30.0 - Upgrade
Upgrade
mcpto a version that resolves this vulnerability.Fixed in 2.2.0 - Configuration
For servers on version 1.12.0 or later where per-session state is unnecessary, set stateless_http=True.
MCP Python SDK Streamable HTTP stateless_http = true - Configuration
On a small host, lower session_idle_timeout, max_sessions, and max_request_body_size to fit available capacity.
MCP Python SDK Streamable HTTP session_idle_timeout, max_sessions, max_request_body_size = lowered to fit host capacity - Compensating control
Restrict which clients can reach the Streamable HTTP endpoint until the server is upgraded.
Event History
Frequently Asked Questions
Which deployments are exposed to this resource-exhaustion issue?
Stateful Streamable HTTP servers using the MCP Python SDK are affected, including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager. Stateless HTTP, stdio, and SSE transports are not affected.
What does an attacker need to exploit the issue?
An attacker only needs network reachability to the affected Streamable HTTP endpoint. They can send ordinary short requests that create retained session entries and cause memory growth over time.
Does ending or rejecting a session prevent the memory accumulation?
Not reliably. DELETE requests, refused opening requests, and completed sessions can all leave their session entries retained.
What versions contain the fix?
The issue is fixed in MCP Python SDK versions 1.30.0 and 2.2.0. Affected releases are from 1.8.0 until those fixed versions.