MCP Python SDK kept sessions forever, letting memory run out
An advisory published on 15 October 2026 says Streamable HTTP servers in the default stateful mode never reclaimed session state, so any reachable client could grow memory without bound.
By The Agentic Times ·

Anthropic has published a security advisory for the MCP Python SDK describing a resource exhaustion flaw in its Streamable HTTP transport. The advisory, tracked as CVE-2026-59951 and published on 15 October 2026, says that a server running in stateful mode, which is the default, never reclaimed session state. Any client that could reach the endpoint could use ordinary short requests to grow server memory without limit, and only a restart would reclaim it.
According to the advisory, three things went wrong at once. Sessions never expired. A client DELETE request ended a session but left its entry registered. And a session whose first request was refused stayed registered with a running task behind it. Each session also held on to its parsed initialize parameters, and the total number of sessions was unlimited.
The affected versions are 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1. Stateful mode is the default for FastMCP in the 1.x line, for MCPServer and Server.streamable_http_app() in 2.x, and for StreamableHTTPSessionManager. Servers on 1.12.0 or later that pass stateless_http=True keep no sessions and are not affected, and servers using only the stdio or SSE transports are also unaffected. The advisory notes that authentication does not help much here, because it limits who can open sessions rather than how many a token holder can open.
The fix is to upgrade to mcp 1.30.0 or 2.2.0 or later. In those releases a session with no request in flight for session_idle_timeout seconds, which defaults to 1800, is closed, and its ID then answers with a 404. Open streams and in-progress requests keep a session alive. A max_sessions limit, defaulting to 10,000, caps how many sessions can exist at once, and a request that would open another is answered with a 503. Sessions are now discarded as soon as they end, whether by DELETE, by expiry, or because the opening request was refused.
Anthropic is clear that this bounds retention rather than removing it. A live session still holds its initialize parameters, which the advisory says can be up to roughly twice the 4 MiB body limit, and an initialize call with invalid parameters still opens a session that then expires like any other. Operators on small hosts are advised to lower session_idle_timeout, max_sessions and max_request_body_size to fit. Both new settings are keyword arguments on the relevant constructors and can be disabled by passing None. For those who cannot upgrade, the advisory suggests passing stateless_http=True where no per-session state is needed, or restricting who can reach the endpoint.
A second advisory published minutes later the same day, CVE-2026-86063, covers a different problem in Claude Code and Claude Desktop. The plugin install flow checked out a marketplace's pinned commit SHA with git checkout without checking that the resulting HEAD matched the pinned SHA. An attacker controlling a plugin's upstream repository could create a branch named identically to the 40-character SHA, so the checkout would quietly resolve to the attacker's branch tip. Anthropic said users on standard auto-update already have the fix, and credited Or Nevo Michrowski of Air Security for the report.
Sources
- github.comhttps://github.com/advisories/GHSA-84m7-p3x7-pcfv
- github.comhttps://github.com/advisories/GHSA-pq7j-f95f-qfcv
