CVE-2026-63128: 
Model Context Protocol Analyse et atténuation des vulnérabilités

CVE-2026-63128 is an unauthenticated permanent session-table memory leak in the rmcp crate's stateful Streamable HTTP server transport, leading to remote denial of service. The vulnerability affects all versions of the rmcp Rust crate (official SDK for the Model Context Protocol) up to and including 1.7.0 (i.e., < 2.0.0). It was reported by researcher hewei-gikaku, the fix was merged on June 27, 2026 (PR #934), and the advisory (GHSA-9pj6-vhgr-3mwh) was published on June 29, 2026; the CVE was formally published on September 16, 2026. The CVSS v3.1 base score is 7.5 (High) (GitHub Advisory, Red Hat).

The root cause is a logic flaw (CWE-400, CWE-401, CWE-772) in StreamableHttpService::handle_post within crates/rmcp/src/transport/streamable_http_server/tower.rs. In versions prior to 2.0.0, the function calls LocalSessionManager.create_session() — which inserts a LocalSessionHandle (including a tokio mpsc channel) into a RwLock<HashMap<SessionId, LocalSessionHandle>> — before validating whether the incoming JSON-RPC POST is a valid InitializeRequest. When validation subsequently fails (e.g., the message is not an InitializeRequest, or the MCP-Protocol-Version header mismatches the body), the function returns early via one of four error paths (A, B, C, D) without ever calling close_session(). The orphaned LocalSessionHandle and its associated channel internals (~400–550 bytes) remain in the HashMap for the entire server process lifetime, as the only cleanup path (spawn_session_worker) is never reached. The fix in PR #934 reorders the logic to perform all validation checks before calling create_session(), ensuring no session state is allocated for invalid requests (GitHub Advisory, Fix Commit).

Successful exploitation results in unbounded memory growth on the server process, with each malformed request permanently leaking approximately 400–550 bytes of session state. At a measured rate of ~2,174 requests per second from a single Python client, this translates to roughly 3.5 GB of leaked memory per hour and ~84 GB per day, ultimately causing the server process to be OOM-killed. A secondary impact is degraded latency for legitimate clients: as the phantom-entry HashMap grows into millions of entries, every legitimate session operation (lookup, create, close, restore) must acquire the same RwLock, causing write-lock starvation well before memory exhaustion. There is no confidentiality or integrity impact; the vulnerability is a pure availability (denial-of-service) issue (GitHub Advisory).

A fully self-contained proof-of-concept exploit (a Python attack.py script and a Rust server harness) is publicly available in the GitHub Security Advisory, requiring no authentication, no special privileges, and no user interaction (GitHub Advisory). The NVD SSVC assessment classifies exploitation status as poc (proof-of-concept available). The EPSS score is 0.0 and there is no evidence of in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not listed in the CISA KEV catalog. Exploitation is straightforward: any process with TCP connectivity to the server's listening port can trigger the leak with standard HTTP library calls, making it automatable at high request rates.

1. Identify target: Locate an rmcp Streamable HTTP server (version < 2.0.0) listening on a TCP port. In the default configuration, the server binds to 127.0.0.1:8000 with allowed_hosts set to ["localhost", "127.0.0.1", "::1"], making any co-resident process a viable attacker. In LAN deployments with a widened allowed_hosts, the attack is reachable from the network.

2. Craft the malicious payload: Construct a valid JSON-RPC 2.0 POST body that is a ClientJsonRpcMessage::Request but is not an InitializeRequest. Example payload: {"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}. Alternatively, craft an InitializeRequest with a mismatched MCP-Protocol-Version header.

3. Send the HTTP POST request: Issue an HTTP POST to the /mcp endpoint with headers Host: 127.0.0.1:8000, Content-Type: application/json, and Accept: application/json, text/event-stream. The Host header must pass the DNS-rebinding check (validate_dns_rebinding_headers), so use a value in allowed_hosts.

4. Trigger the leak: The server's handle_post calls create_session() (inserting a LocalSessionHandle into the session HashMap), then fails validation and returns HTTP 422 Unexpected message, expect initialize request — without calling close_session(). The session entry is now permanently orphaned in memory.

5. Repeat at high rate: Loop the request in a tight loop (e.g., using Python's http.client with a new connection per request). A single Python client can sustain ~2,174 requests/second, accumulating ~7.8 million leaked entries (~3.5 GB) per hour.

6. Achieve denial of service: As the HashMap grows, legitimate client operations experience increasing RwLock contention and latency degradation. Eventually, the server process is OOM-killed. Restarting the server restores service but does not prevent re-attack (GitHub Advisory).

• Network: High volume of HTTP POST requests to the /mcp endpoint (or configured MCP path) from one or more source IPs, each receiving HTTP 422 responses with body Unexpected message, expect initialize request; sustained request rates of hundreds to thousands per second from a single client.
• Logs: Server access logs showing repeated POST requests to the MCP endpoint returning 422 status codes; absence of corresponding successful session initialization (no HTTP 200 with mcp-session-id response header) for the same source.
• Process/Memory: Monotonically increasing RSS (resident set size) of the rmcp server process with no corresponding increase in legitimate connected clients; server process eventually terminated by the OS OOM killer (oom_kill_process in kernel logs on Linux).
• Application Metrics: LocalSessionManager.sessions HashMap length (if instrumented/logged) growing without bound and never decreasing; increasing tail latency on legitimate MCP client operations correlated with session table growth (GitHub Advisory).

The definitive fix is to upgrade the rmcp crate to version 2.0.0 or later, which reorders handle_post logic to validate the incoming message type and protocol version header before allocating any session state (rmcp v2.0.0 Release, Fix Commit). As interim mitigations for deployments that cannot immediately upgrade: implement rate limiting on incoming HTTP POST requests to the MCP endpoint at the reverse proxy or network layer; restrict allowed_hosts to the minimum necessary set; and monitor server memory consumption and session table size for anomalies. There is no configuration-only workaround within the rmcp library itself for versions prior to 2.0.0.

The fix was authored and merged by maintainer DaleSeo (PR #934, June 27, 2026) and released as part of rmcp v2.0.0 on June 29, 2026, alongside other security fixes including OAuth resource spoofing and SSRF mitigations (rmcp v2.0.0 Release). Downstream projects such as grooveseek and VelesDB noted the vulnerability in their own changelogs and upgraded to rmcp 2.0.0 shortly after the advisory was published. Red Hat's Product Security team filed a high-severity Bugzilla entry (Bug 2535485) on September 16, 2026, tracking the issue for potential impact on Red Hat products (Red Hat Bugzilla). No significant broader media coverage or social media discussion has been identified beyond the GitHub advisory and downstream dependency tracking.