Action not permitted
Modal body text goes here.
Modal Title
Modal Body
GHSA-84M7-P3X7-PCFV
Vulnerability from github – Published: 2026-10-15 20:13 – Updated: 2026-10-15 20:13Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mcp"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0"
},
{
"fixed": "1.30.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "mcp"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59951"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770",
"CWE-772"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:13:13Z",
"nvd_published_at": "2026-10-14T17:18:29Z",
"severity": "MODERATE"
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "GHSA-84m7-p3x7-pcfv",
"modified": "2026-10-15T20:13:13Z",
"published": "2026-10-15T20:13:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion"
}
BREW-CYCODE-CVE-2026-59951 (GHSA-84M7-P3X7-PCFV)
Vulnerability from osv_homebrew – Published: 2026-10-16 08:52 – Updated: 2026-10-16 08:52 – Source websiteSummary
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.
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "mcp",
"resource_purl": "pkg:pypi/mcp@1.30.0",
"upstream_fixed_in": "1.30.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "cycode",
"purl": "pkg:brew/cycode"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/mcp@1.30.0",
"name": "mcp",
"resource": "mcp",
"strategy": "registry",
"subject_version": "1.30.0"
}
]
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "BREW-cycode-CVE-2026-59951",
"modified": "2026-10-16T08:52:01Z",
"published": "2026-10-16T08:52:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion",
"upstream": [
"GHSA-84m7-p3x7-pcfv",
"CVE-2026-59951"
]
}
BREW-FASTMCP-CVE-2026-59951 (GHSA-84M7-P3X7-PCFV)
Vulnerability from osv_homebrew – Published: 2026-10-16 09:13 – Updated: 2026-10-16 09:13 – Source websiteSummary
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.
| URL | Type | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "mcp",
"resource_purl": "pkg:pypi/mcp@2.3.0",
"upstream_fixed_in": "2.2.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "fastmcp",
"purl": "pkg:brew/fastmcp"
},
"ranges": [
{
"events": [
{
"introduced": "2.12.3"
},
{
"fixed": "4.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/mcp@2.3.0",
"name": "mcp",
"resource": "mcp",
"strategy": "registry",
"subject_version": "2.3.0"
}
]
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "BREW-fastmcp-CVE-2026-59951",
"modified": "2026-10-16T09:13:06Z",
"published": "2026-10-16T09:13:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion",
"upstream": [
"GHSA-84m7-p3x7-pcfv",
"CVE-2026-59951"
]
}
BREW-MCP-ATLASSIAN-CVE-2… (GHSA-84M7-P3X7-PCFV)
Vulnerability from osv_homebrew – Published: 2026-10-16 09:30 – Updated: 2026-10-16 09:30 – Source websiteSummary
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.
| URL | Type | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "mcp",
"resource_purl": "pkg:pypi/mcp@1.30.0",
"upstream_fixed_in": "1.30.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "mcp-atlassian",
"purl": "pkg:brew/mcp-atlassian"
},
"ranges": [
{
"events": [
{
"introduced": "0.11.9"
},
{
"fixed": "0.23.1_1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/mcp@1.30.0",
"name": "mcp",
"resource": "mcp",
"strategy": "registry",
"subject_version": "1.30.0"
}
]
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "BREW-mcp-atlassian-CVE-2026-59951",
"modified": "2026-10-16T09:30:02Z",
"published": "2026-10-16T09:30:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion",
"upstream": [
"GHSA-84m7-p3x7-pcfv",
"CVE-2026-59951"
]
}
BREW-MCP-GOOGLE-SHEETS-C… (GHSA-84M7-P3X7-PCFV)
Vulnerability from osv_homebrew – Published: 2026-10-16 08:56 – Updated: 2026-10-16 17:07 – Source websiteSummary
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.
| URL | Type | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "mcp",
"resource_purl": "pkg:pypi/mcp@1.30.0",
"upstream_fixed_in": "1.30.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "mcp-google-sheets",
"purl": "pkg:brew/mcp-google-sheets"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.2"
},
{
"fixed": "0.6.3_5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/mcp@1.30.0",
"name": "mcp",
"resource": "mcp",
"strategy": "registry",
"subject_version": "1.30.0"
}
]
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "BREW-mcp-google-sheets-CVE-2026-59951",
"modified": "2026-10-16T17:07:11Z",
"published": "2026-10-16T08:56:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion",
"upstream": [
"GHSA-84m7-p3x7-pcfv",
"CVE-2026-59951"
]
}
BREW-MCP-PROXY-CVE-2026-59951 (GHSA-84M7-P3X7-PCFV)
Vulnerability from osv_homebrew – Published: 2026-10-16 09:39 – Updated: 2026-10-16 09:39 – Source websiteSummary
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.
| URL | Type | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": "bump",
"range_state": "fixed",
"resource": "mcp",
"resource_purl": "pkg:pypi/mcp@1.30.0",
"upstream_fixed_in": "1.30.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "mcp-proxy",
"purl": "pkg:brew/mcp-proxy"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.2"
},
{
"fixed": "0.12.0_5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/mcp@1.30.0",
"name": "mcp",
"resource": "mcp",
"strategy": "registry",
"subject_version": "1.30.0"
}
]
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "BREW-mcp-proxy-CVE-2026-59951",
"modified": "2026-10-16T09:39:29Z",
"published": "2026-10-16T09:39:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion",
"upstream": [
"GHSA-84m7-p3x7-pcfv",
"CVE-2026-59951"
]
}
BREW-MCPM-CVE-2026-59951 (GHSA-84M7-P3X7-PCFV)
Vulnerability from osv_homebrew – Published: 2026-10-16 09:29 – Updated: 2026-10-16 17:07 – Source websiteSummary
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.
| URL | Type | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "mcp",
"resource_purl": "pkg:pypi/mcp@1.27.2",
"upstream_fixed_in": "1.30.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "mcpm",
"purl": "pkg:brew/mcpm"
},
"ranges": [
{
"events": [
{
"introduced": "1.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/mcp@1.27.2",
"name": "mcp",
"resource": "mcp",
"strategy": "registry",
"subject_version": "1.27.2"
}
]
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "BREW-mcpm-CVE-2026-59951",
"modified": "2026-10-16T17:07:11Z",
"published": "2026-10-16T09:29:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion",
"upstream": [
"GHSA-84m7-p3x7-pcfv",
"CVE-2026-59951"
]
}
BREW-SEMGREP-CVE-2026-59951 (GHSA-84M7-P3X7-PCFV)
Vulnerability from osv_homebrew – Published: 2026-10-16 09:02 – Updated: 2026-10-16 17:07 – Source websiteSummary
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.
| URL | Type | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "mcp",
"resource_purl": "pkg:pypi/mcp@1.29.0",
"upstream_fixed_in": "1.30.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "semgrep",
"purl": "pkg:brew/semgrep"
},
"ranges": [
{
"events": [
{
"introduced": "1.140.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/mcp@1.29.0",
"name": "mcp",
"resource": "mcp",
"strategy": "registry",
"subject_version": "1.29.0"
}
]
},
"details": "### Summary\nIn affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:\n\n- sessions did not expire;\n- a client `DELETE` ended the session but left its entry registered;\n- a session whose first request was refused stayed registered with a running task.\n\nEach 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.\n\n### Am I affected?\nYes, 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:\n\n- `FastMCP` (1.x)\n- `MCPServer` and `Server.streamable_http_app()` (2.x)\n- `StreamableHTTPSessionManager`\n\nAffected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.\n\nNot affected:\n\n- servers on 1.12.0 or later passing `stateless_http=True` (no sessions are kept)\n- servers using only the stdio or SSE transports\n\nAuthentication limits who can open sessions, not how many a token holder can open.\n\n### Fix\nUpgrade to `mcp` 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:\n\n- 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;\n- at most `max_sessions` sessions exist at once (default 10000); a request that would open another is answered `503`;\n- a session is discarded as soon as it ends, whether by `DELETE`, expiry, or a refused opening request.\n\nBoth settings are keyword arguments on `FastMCP(...)` (1.x), `MCPServer.run()` / `streamable_http_app()` (2.x) and `StreamableHTTPSessionManager`; `None` disables them.\n\nThis 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.\n\nIf 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.",
"id": "BREW-semgrep-CVE-2026-59951",
"modified": "2026-10-16T17:07:11Z",
"published": "2026-10-16T09:02:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59951"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/python-sdk"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion",
"upstream": [
"GHSA-84m7-p3x7-pcfv",
"CVE-2026-59951"
]
}
CVE-2026-59951 (GCVE-0-2026-59951)
Vulnerability from cvelistv5 – Published: 2026-10-14 16:22 – Updated: 2026-10-15 15:07| URL | Tags |
|---|---|
| https://github.com/modelcontextprotocol/python-sd… | x_refsource_CONFIRM |
| https://github.com/modelcontextprotocol/python-sd… | x_refsource_MISC |
| https://github.com/modelcontextprotocol/python-sd… | x_refsource_MISC |
| https://github.com/modelcontextprotocol/python-sd… | x_refsource_MISC |
| https://github.com/modelcontextprotocol/python-sd… | x_refsource_MISC |
| https://github.com/modelcontextprotocol/python-sd… | x_refsource_MISC |
| https://github.com/modelcontextprotocol/python-sd… | x_refsource_MISC |
| Vendor | Product | Version | |
|---|---|---|---|
| modelcontextprotocol | python-sdk |
Affected:
>= 1.8.0, < 1.30.0
Affected: >= 2.0.0, < 2.2.0 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-59951",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T13:55:54.339140Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T15:07:43.737Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "python-sdk",
"vendor": "modelcontextprotocol",
"versions": [
{
"status": "affected",
"version": "\u003e= 1.8.0, \u003c 1.30.0"
},
{
"status": "affected",
"version": "\u003e= 2.0.0, \u003c 2.2.0"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "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."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400: Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-772",
"description": "CWE-772: Missing Release of Resource after Effective Lifetime",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-14T16:22:31.653Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-84m7-p3x7-pcfv"
},
{
"name": "https://github.com/modelcontextprotocol/python-sdk/pull/3395",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3395"
},
{
"name": "https://github.com/modelcontextprotocol/python-sdk/pull/3426",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/modelcontextprotocol/python-sdk/pull/3426"
},
{
"name": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/92120b4b0f50385af096592d7cee932fc1d994e7"
},
{
"name": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/modelcontextprotocol/python-sdk/commit/d2290ca3434731b68ea3e2270bc06a6e6575931b"
},
{
"name": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0"
},
{
"name": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0"
}
],
"source": {
"advisory": "GHSA-84m7-p3x7-pcfv",
"discovery": "UNKNOWN"
},
"title": "MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-59951",
"datePublished": "2026-10-14T16:22:31.653Z",
"dateReserved": "2026-07-07T18:49:15.607Z",
"dateUpdated": "2026-10-15T15:07:43.737Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.