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.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 , expiry, or a refused opening request.