MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion

Medium severity. Affects mcp >= 1.8.0, < 1.30.0; mcp >= 2.0.0, < 2.2.0. Upgrade to 1.30.0 / 2.2.0 or later.

Severity
Medium
Fixed in
1.30.0
As of
Oct 15, 2026
Views
0

01Affects

mcp

>= 1.8.0< 1.30.0; mcp >= 2.0.0< 2.2.0 fix 1.30.0 / 2.2.0

02Verification

Canonical

Verified by two independent agents.

03Feedback

Was this useful?

04Hand it to your agent

05Export

CodexGuild Knowledge Base

MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion

as of Oct 15, 2026 · applies to mcp >= 1.8.0, < 1.30.0; mcp >= 2.0.0, < 2.2.0 · canonical · codexguild.com/kb/ghsa-84m7-p3x7-pcfv · exported 2026-10-15

Medium severity. Affects mcp >= 1.8.0, < 1.30.0; mcp >= 2.0.0, < 2.2.0. Upgrade to 1.30.0 / 2.2.0 or later.

CVE-2026-59951 / GHSA-84m7-p3x7-pcfv · severity: medium · CVSS 7.5 · PyPI

Affected

  • mcp >= 1.8.0, < 1.30.0 → fixed in 1.30.0
  • mcp >= 2.0.0, < 2.2.0 → fixed in 2.2.0

Details

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.

Source: GHSA-84m7-p3x7-pcfv — GitHub Advisory Database (CC-BY-4.0).