Incident: Sessions nobody ever reclaimed
Module 2 · Incident file · About 35 minutes · Needs: Lessons 2 and 3 of this module, and the Module 2 lab's examples/m02_server.py in your repositoryWhat happened
On 30 September 2026 the maintainers of the official MCP Python SDK, the mcp package this course pins, published advisory GHSA-84m7-p3x7-pcfv (CVE-2026-59951), "Streamable HTTP sessions were never reclaimed by default and kept their initialize payloads", rated high, CVSS 7.5 (advisory). Lesson 2 summarised it in one paragraph under "In production"; this file tells the whole story and replays it on Nare's server.
The advisory says that in stateful mode, the default, "sessions did not expire", "a client DELETE ended the session but left its entry registered", and "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. So "a client that could reach the endpoint could grow server memory without bound using ordinary short requests; only a restart reclaimed it." Affected: 1.8.0 to 1.29.1 and 2.0.0 to 2.1.1. Authentication did not help: it "limits who can open sessions, not how many a token holder can open."
The pieces were reported in public first. Issue #2455 (16 April 2026) noted that session_idle_timeout existed on the session manager but could not be set through streamable_http_app() (issue). Issue #3228 (30 July) measured "roughly 22.6 KiB per rejected request" left behind; its author chose not to file it as a vulnerability because 200 valid initialize requests already created 200 sessions (issue). Issue #3300 (13 August) isolated the DELETE leak (issue). Pull request #3395, merged on 28 August, fixed all three (PR); versions 2.2.0 and 1.30.0 shipped it on 7 September (release notes). The advisory names no attack that used it; the cost it describes is a server that runs out of memory.