AI and data stack advisories

Severe, 6 weeks606Projects324

606 severe, 6 weeks · 324 projects

MCP SDKsGHSA-84m7-p3x7-pcfv

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

MCP SDKs

CVE-2026-59951 · Published Oct 15, 2026

Medium7.5
Fix: upgrade to 1.30.0 or later (2 fixed versions below)
GitHub advisory

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...

Affected versions

PackageAffectedFixed in
mcp
PyPI
>= 1.8.0, < 1.30.01.30.0
>= 2.0.0, < 2.2.02.2.0
Details and references

### 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.

CVSS 3.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Severity from
GitHub (reviewed advisory)
Weakness
CWE-400, CWE-770, CWE-772
Also known as
CVE-2026-59951

More MCP SDKs advisories

All MCP SDKs