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.
References
Summary
In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:
DELETEended the session but left its entry registered;Each session also kept its parsed
initializeparameters, 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)MCPServerandServer.streamable_http_app()(2.x)StreamableHTTPSessionManagerAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.
Not affected:
stateless_http=True(no sessions are kept)Authentication limits who can open sessions, not how many a token holder can open.
Fix
Upgrade to
mcp1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:session_idle_timeoutseconds (default 1800) is closed and its ID then answers404; open streams and in-progress requests keep it alive;max_sessionssessions exist at once (default 10000); a request that would open another is answered503;DELETE, expiry, or a refused opening request.Both settings are keyword arguments on
FastMCP(...)(1.x),MCPServer.run()/streamable_http_app()(2.x) andStreamableHTTPSessionManager;Nonedisables them.This bounds retention rather than eliminating it: a live session still holds its
initializeparameters (up to roughly twice the 4 MiB body limit), and aninitializewith invalid parameters still opens a session that expires like any other. On a small host, lowersession_idle_timeout,max_sessionsandmax_request_body_sizeto 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.References