CVE-2026-59951: MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion

In StreamableHTTPSessionManager, a session stayed registered after DELETE, a session whose first request was refused stayed registered with a running task, and each session held its parsed initialize parameters. With no limit on session count, a client that reaches the endpoint can open sessions in a loop and exhaust memory, which takes the MCP server down for all users. Only a restart reclaims the memory.

No credentials are needed when the endpoint is open. Authentication limits who can open sessions, not how many a token holder opens. The result is denial of service only, with no data exposure. Servers on stdio or SSE, and servers with stateless_http=True on 1.12.0 or later, keep no sessions and are not affected.

Affected: mcp 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1, when serving Streamable HTTP in stateful mode. That is the default for FastMCP (1.x), MCPServer and Server.streamable_http_app() (2.x), and StreamableHTTPSessionManager.

pip show mcp

Check whether your code sets stateless_http=True.

Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x):

pip install --upgrade mcp

The patched versions close a session after session_idle_timeout seconds without a request in flight (default 1800, the ID then answers 404). They cap sessions at max_sessions (default 10000, further requests get 503) and discard sessions when they end. Both are keyword arguments, and None disables them.

This bounds retention only. A live session still holds its initialize parameters, up to about twice the 4 MiB body limit. On small hosts, lower session_idle_timeout, max_sessions and max_request_body_size. Without an upgrade, use stateless_http=True on 1.12.0 or later, or restrict who can reach the endpoint.

Watch the MCP server process for steadily rising memory that falls only on restart, and for large numbers of POST requests with initialize bodies or DELETE calls from one source in access logs. After patching, many 404 and 503 answers on the MCP path point to the new limits being hit.

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.streamable_http_app() (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 stateless_http=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 session_idle_timeout seconds (default 1800) is closed and its ID then answers 404; open streams and in-progress requests keep it alive;
• at most max_sessions 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() / streamable_http_app() (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 session_idle_timeout, max_sessions and max_request_body_size to fit.

If you cannot upgrade yet, pass stateless_http=True (1.12.0 or later) where you need no per-session state, or restrict who can reach the endpoint.