AI Security Incident

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

What Happened

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

Why This Matters

Current evidence identifies a security issue involving the affected technology, but does not yet support a more specific impact claim.

Recommended Action

Confirm whether and is present in your environment and review vendor guidance for this report. Apply available patches or mitigations if your deployment matches the described conditions.

Exposure

Exposure reason: This incident does not currently match a technology in My Interests.

Exploitation status: UNKNOWN

Affected versions: 1.29.1

Primary entities:

Timeline

• Incident first seen
  Oct 16, 2026 01:43

  BugSkan first recorded this incident.

• MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion
  Oct 16, 2026 01:43

  GitHub Advisory Database · Research

Sources

Related Incidents

Other BugSkan incidents that share identifiers, products, or vendors with this report.

My Interests Match