Modelcontextprotocol
Monthly
Cross-session task access in the MCP TypeScript SDK (@modelcontextprotocol/sdk 1.24.0 through 1.31.0) allows any client sharing a single InMemoryTaskStore to list, read, and cancel other clients' experimental task records and results, an IDOR-style authorization bypass rated 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L) with high confidentiality impact and low integrity/availability impact. The flaw is only reachable where an HTTP MCP server explicitly passes a shared taskStore to McpServer or Server and serves multiple sessions from it using the deprecated experimental tasks feature; stdio servers, stateless HTTP servers, and one-store-per-session deployments are not exposed, and 2.x packages are unaffected. There is no public exploit identified at time of analysis and no confirmed active exploitation; the vendor patched the SDK in 1.32.0 by binding each task to the session that created it.
Unbounded HTTP request-body buffering in the Model Context Protocol Python SDK (the 'mcp' package) before 1.29.1 and in 2.0.0a1 through 2.0.1 allows unauthenticated remote attackers who can reach an exposed HTTP transport endpoint to exhaust server memory and potentially terminate the process. The Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes read complete request bodies without any maximum-size check, so a single large declared or streamed body can consume multiple times its own size in process memory and repeated requests can drive sustained memory pressure. Per the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) the impact is availability-only, and no public exploit code was identified at time of analysis; stdio-only servers and deployments behind an effective upstream request-size limit are not affected. This is a genuine but bounded-priority availability issue - the fix is a vendor-released patch in 1.29.1 and 2.1.0 that enforces a 4 MiB default body cap and returns HTTP 413, and the primary residual exposure is default HTTP deployments with no reverse-proxy or gateway body limit.
Unbounded HTTP request-body buffering in the Model Context Protocol (MCP) Java SDK lets an unauthenticated remote client exhaust the JVM heap and render an MCP server unavailable. The flaw affects the Servlet-based SSE, Streamable HTTP, and Stateless server transports in io.modelcontextprotocol.sdk:mcp 0.8.0-0.12.0, mcp-core 0.13.0-0.18.3, 1.0.0-1.1.3, and 2.0.0-M1-2.0.0; a client simply streams an arbitrarily large POST body (including via chunked transfer encoding) until OutOfMemory conditions make the process unresponsive. Rated CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affecting availability only, the impact is materially reduced for deployments that require authentication, enforce Origin/Host validation, or sit behind a reverse proxy, load balancer, or API gateway with a maximum-body-size limit, all of which reject the oversized request before the vulnerable read; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Memory exhaustion in the Model Context Protocol (MCP) Kotlin SDK through version 0.15.0 allows unauthenticated remote clients to drive a server into denial of service by sending WebSocket frames whose headers declare payloads approaching 2 GiB, forcing the server to attempt huge heap allocations before any frame body is received. The flaw lives in the SDK's Application.mcpWebSocket extension, which installs Ktor WebSockets without a maxFrameSize limit, and because that unprotected configuration is the installed default, no special toggle or misconfiguration is required. Impact is availability-only (no confidentiality or integrity loss), the practical limiting factor is network reachability to an exposed WebSocket endpoint running an affected version, and no public exploit code or active exploitation has been identified at time of analysis.
OAuth access-token theft in the rmcp Rust SDK (the official Rust SDK for the Model Context Protocol) before 2.0.0 allows a malicious MCP server to harvest a victim's legitimate bearer token by publishing RFC 9728 protected-resource metadata that names a different, legitimate MCP resource together with that resource's authorization server. The OAuth client transport never verifies that the returned `resource` identifier matches the MCP server URL it was actually configured to contact, so a victim who connects and completes the normal authorization/consent flow receives a genuine access token and then sends it to the attacker's endpoint, letting the attacker replay it against the legitimate MCP resource within the granted scopes. Exploitation requires the user to be induced to connect to the attacker-controlled server and to complete consent (UI:R; CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N, SSVC Automatable=no), publicly available exploit code exists per the SSVC exploitation signal, and there is no CISA KEV entry confirming active exploitation.
Unbounded memory growth in the stateful Streamable HTTP transport of the rmcp Rust SDK (crates/rmcp, all versions prior to 2.0.0) lets remote, unauthenticated attackers permanently leak session state and eventually crash the server. A crafted JSON-RPC POST that is either not an initialization request, or an initialization request whose MCP-Protocol-Version header disagrees with its body, causes StreamableHttpService::handle_post to call LocalSessionManager.create_session before the message is validated; when validation then fails, the handler returns without removing the inserted LocalSessionHandle, so each request leaves a permanent entry in the shared session table. Because exploitation requires sustained repetition to exhaust memory and degrade legitimate clients through lock contention, CISA SSVC rates it PoC-exploitable but not automatable, while publicly available exploit code exists and CVSS 3.1 scores it 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), with availability as the only impacted security property.
Uncontrolled memory allocation in the official Model Context Protocol Ruby SDK (mcp gem) before 0.23.0 lets an unauthenticated remote attacker crash MCP servers by sending a single oversized JSON-RPC POST. The StreamableHTTPTransport read the entire request body into memory and parsed it with no size or JSON-nesting cap, so one request can allocate gigabytes and OOM-kill the worker (CVSS 7.5, availability-only impact). No public exploit identified at time of analysis, but the fix commit and 4 MiB default limit are public, making the mechanism trivially reproducible.
Session hijacking in the MCP Ruby SDK (mcp gem) before 0.23.0 lets an attacker who obtains a valid session ID issue tools/call requests that execute inside the victim's session, because StreamableHTTPTransport validates only session existence and idle timeout without binding a session to its owner. Affected deployments are those exposing the streamable HTTP transport; the flaw enables cross-session action execution and in-flight request tampering (e.g. notifications/cancelled). No public exploit identified at time of analysis and the issue is not in CISA KEV; the vendor CVSS 4.0 score is 8.3 (integrity-focused).
Cross-origin WebSocket hijacking in the Model Context Protocol Python SDK (mcp on PyPI) before 1.28.1 lets a remote web page connect to any application exposing the deprecated mcp.server.websocket.websocket_server transport, because that transport accepted handshakes without Host or Origin validation and offered no SDK-level control to restrict connecting origins. A malicious site loaded in a victim's browser can therefore open an MCP session against a locally reachable server and drive its tools. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; the tags flag it as information disclosure.
Missing authorization in the MCP Python SDK (the `mcp` PyPI package) versions 1.23.0 through 1.27.1 lets any authenticated client of a multi-client server enumerate, read the results of, consume messages from, or cancel tasks belonging to other clients. The default handlers wired up by `server.experimental.enable_tasks()` for tasks/list, tasks/get, tasks/result, and tasks/cancel key solely on the task identifier and never bind a task to the session that created it. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the upstream fix, deprecation warnings, and detailed advisory confirm the flaw; it is resolved in version 1.27.2.
Cross-session message injection in the MCP Python SDK (the 'mcp' package on PyPI) prior to 1.27.2 allows an authenticated client holding a valid bearer token to hijack another principal's session on the SSE and stateful Streamable HTTP transports. Because SseServerTransport and StreamableHTTPSessionManager route inbound requests using only the session_id query parameter or Mcp-Session-Id header - never checking that the caller is the same authenticated principal who created the session - any bearer-token-authenticated client who learns a victim's session ID can inject arbitrary JSON-RPC messages into that session. There is no public exploit identified at time of analysis and no CISA KEV listing; the flaw is fixed in version 1.27.2.
Client-side server-side request forgery and denial of service in the official Model Context Protocol Python SDK: when a connected MCP server declares a tool outputSchema containing an $id or an out-of-document $ref/$dynamicRef (http://, https:// or file://), the SDK's ClientSession, ClientSessionGroup and 2.x Client classes resolve that reference with jsonschema's default resolver, so the client fetches the URL or reads the local file from its own network and filesystem position and blocks the asyncio event loop for every session in the process while doing so. Applications using the SDK purely as a server are not affected; the vulnerable code runs only when a client invokes tools on a server the operator does not fully control. Versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 are affected and are fixed in 1.30.0 and 2.2.0 respectively; no public exploit has been identified at time of analysis, the fetched content is never returned to the malicious server (blind SSRF), and the CVSS 6.5 score reflects availability impact (A:H) rather than confidentiality.
Cross-origin redirect handling in the Model Context Protocol Python SDK (published on PyPI as `mcp`) leaks caller-supplied custom credential headers, and on 307/308 responses the request body, to any host a trusted MCP endpoint redirects to. Affected are HTTP client paths using `streamable_http_client`, `streamablehttp_client`, `sse_client`, `ClientSessionGroup` with HTTP server parameters, the OAuth client providers, or the internal `create_mcp_http_client` helper in versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1, where redirect following was enabled by default or by a caller-supplied client with `follow_redirects=True`. Impact is conditional: a lone `Authorization` bearer header is dropped by the HTTP library on cross-origin hops, the body is only re-sent on 307/308, MCP servers and stdio clients are unaffected, and a malicious MCP server gains nothing because it already receives the requests directly, so exploitation depends on an attacker influencing where a trusted endpoint redirects (stale redirect to a lapsed domain, misrouted proxy rule, attacker-influenced redirect logic). No public exploit code or CISA KEV entry was identified at time of analysis, and the vendor-released fix is available in 1.30.0 (1.x) and 2.2.0 (2.x).
Resource-confusion in the Model Context Protocol Python SDK (pip package mcp) causes server-side bearer authentication to accept a token that was issued for a different service. The flaw affects HTTP servers built on the SDK that configure auth=AuthSettings(...) with a token_verifier, and it only bites when the same authorization server issues tokens for multiple resources and the deployment's TokenVerifier does not itself check the token's aud audience; in that setup an attacker who already holds a valid bearer token for another service can present it to the wrong MCP server and exercise the access it carries (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, CWE-863). Affected builds are mcp 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1; single-resource deployments, verifiers that already validate aud, and correctly configured patched versions are not exposed. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; exploitation requires a pre-existing token plus a specific multi-resource authorization-server topology.
Unbounded server-side memory growth in stateful Streamable HTTP servers built on the MCP Python SDK (the 'mcp' package on PyPI) lets any client that can reach the endpoint exhaust process memory and force a restart. Versions 1.8.0 and later on the affected lines - including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager - retain session entries (with their parsed initialize parameters) that are never aged out or capped, so repeated ordinary short requests accumulate indefinitely; the CVSS 4.0 base score of 6.9 reflects availability-only impact, and no public exploit code has been identified at time of analysis. Stateless HTTP, stdio, and SSE transports are not affected, and the issue is fixed in versions 1.30.0 and 2.2.0.
Server-side request forgery in the Model Context Protocol reference Fetch Tool (mcp-server-fetch, and the related mcp-server-everything) up to 2026.6.4 lets unauthenticated remote callers direct the fetch_url function at internal or otherwise restricted destinations by supplying a crafted url/path argument, with no destination validation in the default configuration. Impact is bounded but real: the assessed vector rates confidentiality and integrity impact as low with no availability impact, and the primary abuse case is reaching loopback services, private RFC1918 ranges, and cloud instance metadata endpoints (for example 169.254.169.254 and 100.100.100.100) from the server's network position rather than executing code. Publicly available exploit code exists (a public GitHub issue plus a VulDB entry) and the CVSS 4.0 vector carries an E:P proof-of-concept maturity flag, but there is no confirmed active exploitation (no CISA KEV listing); exposure depends on whether the Fetch Tool and its URL argument are reachable by an attacker, since these are reference servers frequently run locally beside an AI assistant.
Uncontrolled memory growth in the MCP Ruby SDK (mcp gem) prior to 0.23.0 allows any peer process communicating via stdio to OOM-kill the host Ruby process by sending a continuous byte stream without a newline, exhausting available system memory. Both the server-side MCP::Server::Transports::StdioTransport and client-side MCP::Client::Stdio components are affected, meaning Ruby applications acting as either MCP servers or MCP clients are vulnerable. No public exploit has been identified at time of analysis, and no CISA KEV listing exists, but the attack is mechanically trivial for any process with stdio access to the target.
Unbounded session growth in MCP Ruby SDK's StreamableHTTPTransport allows unauthenticated remote attackers to exhaust server process memory by repeatedly sending initialize requests. Affected versions prior to 0.23.0 defaulted to no session expiry and no concurrent session cap, meaning each initialize request created a persistent ServerSession object that was never reclaimed without an explicit client DELETE. No public exploit has been identified at time of analysis, and exploitation is not confirmed by CISA KEV, but the attack is trivially automatable given the network-accessible, unauthenticated HTTP endpoint.
DNS rebinding in MCP Ruby SDK's StreamableHTTPTransport (mcp gem, all versions prior to 0.23.0) exposes locally running MCP servers to browser-driven tool invocation without authentication. The transport accepted HTTP requests without validating Host or Origin headers, allowing a malicious webpage to exploit short-TTL DNS re-resolution to reach the victim's loopback-bound server and call any registered MCP tool. No public exploit code is identified at time of analysis, and no CISA KEV listing exists; however, the CVSS 4.0 score of 6.9 with VC:H and SC:H reflects a meaningful confidentiality risk for developers actively using local MCP tooling alongside a browser.
Cross-session task access in the MCP TypeScript SDK (@modelcontextprotocol/sdk 1.24.0 through 1.31.0) allows any client sharing a single InMemoryTaskStore to list, read, and cancel other clients' experimental task records and results, an IDOR-style authorization bypass rated 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L) with high confidentiality impact and low integrity/availability impact. The flaw is only reachable where an HTTP MCP server explicitly passes a shared taskStore to McpServer or Server and serves multiple sessions from it using the deprecated experimental tasks feature; stdio servers, stateless HTTP servers, and one-store-per-session deployments are not exposed, and 2.x packages are unaffected. There is no public exploit identified at time of analysis and no confirmed active exploitation; the vendor patched the SDK in 1.32.0 by binding each task to the session that created it.
Unbounded HTTP request-body buffering in the Model Context Protocol Python SDK (the 'mcp' package) before 1.29.1 and in 2.0.0a1 through 2.0.1 allows unauthenticated remote attackers who can reach an exposed HTTP transport endpoint to exhaust server memory and potentially terminate the process. The Streamable HTTP session manager, the SSE message endpoint, and the OAuth authorization-server routes read complete request bodies without any maximum-size check, so a single large declared or streamed body can consume multiple times its own size in process memory and repeated requests can drive sustained memory pressure. Per the CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) the impact is availability-only, and no public exploit code was identified at time of analysis; stdio-only servers and deployments behind an effective upstream request-size limit are not affected. This is a genuine but bounded-priority availability issue - the fix is a vendor-released patch in 1.29.1 and 2.1.0 that enforces a 4 MiB default body cap and returns HTTP 413, and the primary residual exposure is default HTTP deployments with no reverse-proxy or gateway body limit.
Unbounded HTTP request-body buffering in the Model Context Protocol (MCP) Java SDK lets an unauthenticated remote client exhaust the JVM heap and render an MCP server unavailable. The flaw affects the Servlet-based SSE, Streamable HTTP, and Stateless server transports in io.modelcontextprotocol.sdk:mcp 0.8.0-0.12.0, mcp-core 0.13.0-0.18.3, 1.0.0-1.1.3, and 2.0.0-M1-2.0.0; a client simply streams an arbitrarily large POST body (including via chunked transfer encoding) until OutOfMemory conditions make the process unresponsive. Rated CVSS 3.1 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and affecting availability only, the impact is materially reduced for deployments that require authentication, enforce Origin/Host validation, or sit behind a reverse proxy, load balancer, or API gateway with a maximum-body-size limit, all of which reject the oversized request before the vulnerable read; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Memory exhaustion in the Model Context Protocol (MCP) Kotlin SDK through version 0.15.0 allows unauthenticated remote clients to drive a server into denial of service by sending WebSocket frames whose headers declare payloads approaching 2 GiB, forcing the server to attempt huge heap allocations before any frame body is received. The flaw lives in the SDK's Application.mcpWebSocket extension, which installs Ktor WebSockets without a maxFrameSize limit, and because that unprotected configuration is the installed default, no special toggle or misconfiguration is required. Impact is availability-only (no confidentiality or integrity loss), the practical limiting factor is network reachability to an exposed WebSocket endpoint running an affected version, and no public exploit code or active exploitation has been identified at time of analysis.
OAuth access-token theft in the rmcp Rust SDK (the official Rust SDK for the Model Context Protocol) before 2.0.0 allows a malicious MCP server to harvest a victim's legitimate bearer token by publishing RFC 9728 protected-resource metadata that names a different, legitimate MCP resource together with that resource's authorization server. The OAuth client transport never verifies that the returned `resource` identifier matches the MCP server URL it was actually configured to contact, so a victim who connects and completes the normal authorization/consent flow receives a genuine access token and then sends it to the attacker's endpoint, letting the attacker replay it against the legitimate MCP resource within the granted scopes. Exploitation requires the user to be induced to connect to the attacker-controlled server and to complete consent (UI:R; CVSS 3.1 vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N, SSVC Automatable=no), publicly available exploit code exists per the SSVC exploitation signal, and there is no CISA KEV entry confirming active exploitation.
Unbounded memory growth in the stateful Streamable HTTP transport of the rmcp Rust SDK (crates/rmcp, all versions prior to 2.0.0) lets remote, unauthenticated attackers permanently leak session state and eventually crash the server. A crafted JSON-RPC POST that is either not an initialization request, or an initialization request whose MCP-Protocol-Version header disagrees with its body, causes StreamableHttpService::handle_post to call LocalSessionManager.create_session before the message is validated; when validation then fails, the handler returns without removing the inserted LocalSessionHandle, so each request leaves a permanent entry in the shared session table. Because exploitation requires sustained repetition to exhaust memory and degrade legitimate clients through lock contention, CISA SSVC rates it PoC-exploitable but not automatable, while publicly available exploit code exists and CVSS 3.1 scores it 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), with availability as the only impacted security property.
Uncontrolled memory allocation in the official Model Context Protocol Ruby SDK (mcp gem) before 0.23.0 lets an unauthenticated remote attacker crash MCP servers by sending a single oversized JSON-RPC POST. The StreamableHTTPTransport read the entire request body into memory and parsed it with no size or JSON-nesting cap, so one request can allocate gigabytes and OOM-kill the worker (CVSS 7.5, availability-only impact). No public exploit identified at time of analysis, but the fix commit and 4 MiB default limit are public, making the mechanism trivially reproducible.
Session hijacking in the MCP Ruby SDK (mcp gem) before 0.23.0 lets an attacker who obtains a valid session ID issue tools/call requests that execute inside the victim's session, because StreamableHTTPTransport validates only session existence and idle timeout without binding a session to its owner. Affected deployments are those exposing the streamable HTTP transport; the flaw enables cross-session action execution and in-flight request tampering (e.g. notifications/cancelled). No public exploit identified at time of analysis and the issue is not in CISA KEV; the vendor CVSS 4.0 score is 8.3 (integrity-focused).
Cross-origin WebSocket hijacking in the Model Context Protocol Python SDK (mcp on PyPI) before 1.28.1 lets a remote web page connect to any application exposing the deprecated mcp.server.websocket.websocket_server transport, because that transport accepted handshakes without Host or Origin validation and offered no SDK-level control to restrict connecting origins. A malicious site loaded in a victim's browser can therefore open an MCP session against a locally reachable server and drive its tools. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; the tags flag it as information disclosure.
Missing authorization in the MCP Python SDK (the `mcp` PyPI package) versions 1.23.0 through 1.27.1 lets any authenticated client of a multi-client server enumerate, read the results of, consume messages from, or cancel tasks belonging to other clients. The default handlers wired up by `server.experimental.enable_tasks()` for tasks/list, tasks/get, tasks/result, and tasks/cancel key solely on the task identifier and never bind a task to the session that created it. There is no public exploit identified at time of analysis and it is not in CISA KEV, but the upstream fix, deprecation warnings, and detailed advisory confirm the flaw; it is resolved in version 1.27.2.
Cross-session message injection in the MCP Python SDK (the 'mcp' package on PyPI) prior to 1.27.2 allows an authenticated client holding a valid bearer token to hijack another principal's session on the SSE and stateful Streamable HTTP transports. Because SseServerTransport and StreamableHTTPSessionManager route inbound requests using only the session_id query parameter or Mcp-Session-Id header - never checking that the caller is the same authenticated principal who created the session - any bearer-token-authenticated client who learns a victim's session ID can inject arbitrary JSON-RPC messages into that session. There is no public exploit identified at time of analysis and no CISA KEV listing; the flaw is fixed in version 1.27.2.
Client-side server-side request forgery and denial of service in the official Model Context Protocol Python SDK: when a connected MCP server declares a tool outputSchema containing an $id or an out-of-document $ref/$dynamicRef (http://, https:// or file://), the SDK's ClientSession, ClientSessionGroup and 2.x Client classes resolve that reference with jsonschema's default resolver, so the client fetches the URL or reads the local file from its own network and filesystem position and blocks the asyncio event loop for every session in the process while doing so. Applications using the SDK purely as a server are not affected; the vulnerable code runs only when a client invokes tools on a server the operator does not fully control. Versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 are affected and are fixed in 1.30.0 and 2.2.0 respectively; no public exploit has been identified at time of analysis, the fetched content is never returned to the malicious server (blind SSRF), and the CVSS 6.5 score reflects availability impact (A:H) rather than confidentiality.
Cross-origin redirect handling in the Model Context Protocol Python SDK (published on PyPI as `mcp`) leaks caller-supplied custom credential headers, and on 307/308 responses the request body, to any host a trusted MCP endpoint redirects to. Affected are HTTP client paths using `streamable_http_client`, `streamablehttp_client`, `sse_client`, `ClientSessionGroup` with HTTP server parameters, the OAuth client providers, or the internal `create_mcp_http_client` helper in versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1, where redirect following was enabled by default or by a caller-supplied client with `follow_redirects=True`. Impact is conditional: a lone `Authorization` bearer header is dropped by the HTTP library on cross-origin hops, the body is only re-sent on 307/308, MCP servers and stdio clients are unaffected, and a malicious MCP server gains nothing because it already receives the requests directly, so exploitation depends on an attacker influencing where a trusted endpoint redirects (stale redirect to a lapsed domain, misrouted proxy rule, attacker-influenced redirect logic). No public exploit code or CISA KEV entry was identified at time of analysis, and the vendor-released fix is available in 1.30.0 (1.x) and 2.2.0 (2.x).
Resource-confusion in the Model Context Protocol Python SDK (pip package mcp) causes server-side bearer authentication to accept a token that was issued for a different service. The flaw affects HTTP servers built on the SDK that configure auth=AuthSettings(...) with a token_verifier, and it only bites when the same authorization server issues tokens for multiple resources and the deployment's TokenVerifier does not itself check the token's aud audience; in that setup an attacker who already holds a valid bearer token for another service can present it to the wrong MCP server and exercise the access it carries (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, CWE-863). Affected builds are mcp 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1; single-resource deployments, verifiers that already validate aud, and correctly configured patched versions are not exposed. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; exploitation requires a pre-existing token plus a specific multi-resource authorization-server topology.
Unbounded server-side memory growth in stateful Streamable HTTP servers built on the MCP Python SDK (the 'mcp' package on PyPI) lets any client that can reach the endpoint exhaust process memory and force a restart. Versions 1.8.0 and later on the affected lines - including FastMCP, MCPServer, Server.streamable_http_app(), and StreamableHTTPSessionManager - retain session entries (with their parsed initialize parameters) that are never aged out or capped, so repeated ordinary short requests accumulate indefinitely; the CVSS 4.0 base score of 6.9 reflects availability-only impact, and no public exploit code has been identified at time of analysis. Stateless HTTP, stdio, and SSE transports are not affected, and the issue is fixed in versions 1.30.0 and 2.2.0.
Server-side request forgery in the Model Context Protocol reference Fetch Tool (mcp-server-fetch, and the related mcp-server-everything) up to 2026.6.4 lets unauthenticated remote callers direct the fetch_url function at internal or otherwise restricted destinations by supplying a crafted url/path argument, with no destination validation in the default configuration. Impact is bounded but real: the assessed vector rates confidentiality and integrity impact as low with no availability impact, and the primary abuse case is reaching loopback services, private RFC1918 ranges, and cloud instance metadata endpoints (for example 169.254.169.254 and 100.100.100.100) from the server's network position rather than executing code. Publicly available exploit code exists (a public GitHub issue plus a VulDB entry) and the CVSS 4.0 vector carries an E:P proof-of-concept maturity flag, but there is no confirmed active exploitation (no CISA KEV listing); exposure depends on whether the Fetch Tool and its URL argument are reachable by an attacker, since these are reference servers frequently run locally beside an AI assistant.
Uncontrolled memory growth in the MCP Ruby SDK (mcp gem) prior to 0.23.0 allows any peer process communicating via stdio to OOM-kill the host Ruby process by sending a continuous byte stream without a newline, exhausting available system memory. Both the server-side MCP::Server::Transports::StdioTransport and client-side MCP::Client::Stdio components are affected, meaning Ruby applications acting as either MCP servers or MCP clients are vulnerable. No public exploit has been identified at time of analysis, and no CISA KEV listing exists, but the attack is mechanically trivial for any process with stdio access to the target.
Unbounded session growth in MCP Ruby SDK's StreamableHTTPTransport allows unauthenticated remote attackers to exhaust server process memory by repeatedly sending initialize requests. Affected versions prior to 0.23.0 defaulted to no session expiry and no concurrent session cap, meaning each initialize request created a persistent ServerSession object that was never reclaimed without an explicit client DELETE. No public exploit has been identified at time of analysis, and exploitation is not confirmed by CISA KEV, but the attack is trivially automatable given the network-accessible, unauthenticated HTTP endpoint.
DNS rebinding in MCP Ruby SDK's StreamableHTTPTransport (mcp gem, all versions prior to 0.23.0) exposes locally running MCP servers to browser-driven tool invocation without authentication. The transport accepted HTTP requests without validating Host or Origin headers, allowing a malicious webpage to exploit short-TTL DNS re-resolution to reach the victim's loopback-bound server and call any registered MCP tool. No public exploit code is identified at time of analysis, and no CISA KEV listing exists; however, the CVSS 4.0 score of 6.9 with VC:H and SC:H reflects a meaningful confidentiality risk for developers actively using local MCP tooling alongside a browser.