Rust MCP server flaw leaks sessions until memory runs out
A GitHub advisory published on 16 September 2026 says unauthenticated requests to rmcp's Streamable HTTP transport leak session entries at roughly 75GB of memory a day.
By The Agentic Times ·

A security advisory published on 16 September 2026 describes an unauthenticated denial-of-service flaw in rmcp, the Rust implementation of the Model Context Protocol server transport. The advisory, tracked as GHSA-9pj6-vhgr-3mwh and CVE-2026-63128, says a remote attacker with no credentials can permanently leak one entry from a server's in-memory session table for every HTTP request sent, until the machine runs out of memory.
According to the advisory, the problem is in the Streamable HTTP server's handle_post function in version 1.7.0. The code creates a session first and validates the request body afterwards. If the body is a well-formed JSON-RPC POST that is not an initialise request, the handler returns an error early and never calls the function that closes the session. The session handle, and the internals of the tokio channel it owns, stay in the server's hash map for the rest of the process's life.
The advisory identifies four separate early-return paths that all skip cleanup, and states that the only code that normally closes a session is the session worker spawn path, or a client-initiated HTTP DELETE. Because the worker exits immediately when the transport is dropped, the advisory says the usual keep-alive and initialisation-timeout cleanup routines cannot run either. They only fire from inside a running worker.
The numbers given are stark relative to the effort involved. A request of about 250 bytes turns into a permanent server-side allocation of roughly 400 to 550 bytes. In the reproduction described in the advisory, a single Python client sustained more than 2,000 leak requests per second. That works out at around 170 million leaked entries per day, or approximately 75GB of resident memory consumed by the session table alone.
The advisory also flags a second effect that bites before memory is exhausted. Every legitimate operation, including session lookup, session restore and a new initialise request, takes a read or write lock on the same structure. As the hash map grows into millions of phantom entries, the advisory says honest clients will see rising tail latency from write-lock starvation.
No unusual setup is needed to be exposed. The advisory states that the bug is reachable with zero authentication, using the default Streamable HTTP server configuration and the default local session manager. It also notes that the issue is separate from the Host-header DNS-rebinding flaw fixed in version 1.4.0, tracked as GHSA-89vp-x53w-74fx and CVE-2026-42559. An attacker can send a legitimate Host header matching the bound address and pass the DNS-rebinding checks normally.
The advisory includes a self-contained proof of concept. It consists of a small Cargo project and a server harness that prints the size of the session hash map once a second, so the growth can be watched from standard output. The advisory says no clone of the rust-sdk repository is required to reproduce the behaviour.
The issue is recorded as reported. Operators running rmcp's Streamable HTTP server transport on an internet-facing address should treat the session table as an unbounded, attacker-controlled data structure until told otherwise by the project.
Sources
- github.comhttps://github.com/advisories/GHSA-9pj6-vhgr-3mwh
