MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion
Summary
In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:
- sessions did not expire;
- a client
DELETEended 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)MCPServerandServer.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_timeoutseconds (default 1800) is closed and its ID then answers404; open streams and in-progress requests keep it alive; - at most
max_sessionssessions exist at once (default 10000); a request that would open another is answered503; - 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.
Czego dotyczy
Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.
| Platforma | Paczka | Podatne wersje | Poprawka w wersji |
|---|---|---|---|
| Python (PyPI) | mcp | >= 1.8.0, < 1.30.0, >= 2.0.0, < 2.2.0 | 1.30.0, 2.2.0 |
Odnośniki
- https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv
- https://nvd.nist.gov/vuln/detail/CVE-2026-59951
- https://github.com/modelcontextprotocol/python-sdk/pull/3395
- https://github.com/modelcontextprotocol/python-sdk/pull/3426
- https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7
- https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b
- https://github.com/modelcontextprotocol/python-sdk
- https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0
- https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0
- Wektor CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H- Słabość (CWE)
CWE-400, CWE-770, CWE-772- Platforma
- Python (PyPI)
- Paczka
mcp- Ujawniono
- 15.10.2026
- Aktualizacja
- 22.10.2026 18:07
Źródła i licencje
OSV / GitHub Advisory Database - GHSA-84m7-p3x7-pcfv - CC BY 4.0
Historia podatności: mcp
Wszystkie opisane podatności tej paczki (Python (PyPI)), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.
- Wszystkich wpisów
- 7
- Pierwsza → ostatnia
- 07.2025 10.2026
- Bez poprawki
- 0
- Wykorzystywana w atakach
- 0
Rozkład istotności
- Wysoka 6
- Średnia 1
Ujawnienia w latach
- 2025: 3
- 2026: 4
-
MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion ten wpis
Dowiedz się, które podatności dotyczą Twojej aplikacji
Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.