MCP · CVE-2026-59951 · AI agents & MCP
FIX → 2.2.0 · 1.30.0
The MCP Python SDK's Streamable HTTP transport in stateful mode (the default) never expires or frees sessions, so each new session stays in memory. A client that can reach the endpoint can use ordinary short requests to grow server memory until the process is restarted.
first public Sep 30, 2026 · 3 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Servers that run the MCP Python SDK over Streamable HTTP in stateful mode, which is the default, and where clients you do not fully trust can reach the endpoint. Authentication limits who can open sessions but not how many a token holder can open. Servers using only stdio or SSE transports, or stateless Streamable HTTP on 1.12.0 or later, are not affected.
Not affected if no-untrusted-clients, stateless-http, stdio-or-sse-only
Who cares fastmcp, mcp, python, self-hosted, streamable-http
pip show mcp (or check the lockfile) and compare the version to the affected ranges: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.FastMCP, , or in your server code and check whether is passed.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)Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
MCPServerServer.streamable_http_app()StreamableHTTPSessionManagerstateless_http=TrueUpgrade to 2.2.0 · 1.30.0
mcp 1.x: upgrade to 1.30.0 or latermcp 2.x: upgrade to 2.2.0 or laterstateless_http=True (1.12.0 or later) where no per-session state is needed, or restrict who can reach the endpoint.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.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.