In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:
DELETE ended the session but left its entry registered;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.
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)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.
Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:
session_idle_timeout seconds (default 1800) is closed and its ID then answers 404; open streams and in-progress requests keep it alive;max_sessions sessions exist at once (default 10000); a request that would open another is answered 503;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.
{
"cwe_ids": [
"CWE-400",
"CWE-770",
"CWE-772"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:13:13Z",
"nvd_published_at": "2026-10-14T17:18:29Z",
"severity": "MODERATE"
}