<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 17 Oct 2026 11:34:41 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-59951 — MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion</title>
      <link>https://db.gcve.eu/vuln/cve-2026-59951</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; modelcontextprotocol python-sdk&lt;/p&gt;
&lt;p&gt;The MCP Python SDK, called mcp on PyPI, is a Python implementation of the Model Context Protocol (MCP). From 1.8.0 until 1.30.0 and 2.2.0, stateful Streamable HTTP servers, including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager, retain session entries without an idle expiration or aggregate session-count limit. DELETE, refused opening requests, and completed sessions do not reliably discard their entries, and each entry can retain parsed initialize parameters. A client that can reach the endpoint can therefore create ordinary short requests that grow server memory without bound until restart. Stateless HTTP, stdio, and SSE transports are not affected. This issue is fixed in versions 1.30.0 and 2.2.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; modelcontextprotocol python-sdk&lt;/p&gt;
&lt;p&gt;The MCP Python SDK, called mcp on PyPI, is a Python implementation of the Model Context Protocol (MCP). From 1.8.0 until 1.30.0 and 2.2.0, stateful Streamable HTTP servers, including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager, retain session entries without an idle expiration or aggregate session-count limit. DELETE, refused opening requests, and completed sessions do not reliably discard their entries, and each entry can retain parsed initialize parameters. A client that can reach the endpoint can therefore create ordinary short requests that grow server memory without bound until restart. Stateless HTTP, stdio, and SSE transports are not affected. This issue is fixed in versions 1.30.0 and 2.2.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-59951</guid>
    </item>
    <item>
      <title>GHSA-84m7-p3x7-pcfv — MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion</title>
      <link>https://db.gcve.eu/vuln/ghsa-84m7-p3x7-pcfv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: mcp&lt;/p&gt;
&lt;p&gt;### Summary
In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### 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:&lt;/p&gt;
&lt;p&gt;- `FastMCP` (1.x)
- `MCPServer` and `Server.streamable_http_app()` (2.x)
- `StreamableHTTPSessionManager`&lt;/p&gt;
&lt;p&gt;Affected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.&lt;/p&gt;
&lt;p&gt;Not affected:&lt;/p&gt;
&lt;p&gt;- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)
- servers using only the stdio or SSE transports&lt;/p&gt;
&lt;p&gt;Authentication limits who can open sessions, not how many a token holder can open.&lt;/p&gt;
&lt;p&gt;### Fix
Upgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:&lt;/p&gt;
&lt;p&gt;- 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 `50…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: mcp&lt;/p&gt;
&lt;p&gt;### Summary
In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### 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:&lt;/p&gt;
&lt;p&gt;- `FastMCP` (1.x)
- `MCPServer` and `Server.streamable_http_app()` (2.x)
- `StreamableHTTPSessionManager`&lt;/p&gt;
&lt;p&gt;Affected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.&lt;/p&gt;
&lt;p&gt;Not affected:&lt;/p&gt;
&lt;p&gt;- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)
- servers using only the stdio or SSE transports&lt;/p&gt;
&lt;p&gt;Authentication limits who can open sessions, not how many a token holder can open.&lt;/p&gt;
&lt;p&gt;### Fix
Upgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:&lt;/p&gt;
&lt;p&gt;- 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 `50…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-84m7-p3x7-pcfv</guid>
    </item>
  </channel>
</rss>
