CVE-2026-67430: Denial of Service via Unbounded Session Retention in Model Context Protocol Ruby SDK

The Model Context Protocol (MCP) Ruby SDK, packaged as the mcp gem, implements client-server coordination for context-sharing APIs, often utilized in large language model (LLM) tooling and autonomous agents. Under stateful deployments, the HTTP transport handler MCP::Server::Transports::StreamableHTTPTransport serves as a Rack-compatible application. It is responsible for parsing connection states, validating incoming requests, and coordinating subsequent Server-Sent Events (SSE) channels. To preserve state across distinct HTTP requests, the class creates and stores session metadata in an in-memory hash map, pairing connections to dedicated execution contexts.

Prior to version 0.23.0, the StreamableHTTPTransport class contained an unchecked resource retention vulnerability. During instantiation, the transport allowed client connections to request stateful workspaces without applying any security boundaries to concurrent session counts or individual lifetimes. The default constructor configured the session idle timeout parameter to nil, which prevented the background cleaning process from spawning. This allowed any unauthenticated actor to create persistent connections and exhaust available server resources.

The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-401 (Missing Release of Memory after Effective Lifetime). Because the SDK is frequently exposed directly to untrusted networks to enable integration with remote LLM agents, this flaw provides a high-impact attack vector. Successful exploitation permits remote, unauthenticated attackers to trigger process-level exhaustion, terminating the application via the operating system's kernel-level Out-of-Memory (OOM) killer.

The root cause of CVE-2026-67430 is a logical omission in the constructor and request-handling routine of the MCP::Server::Transports::StreamableHTTPTransport class. When the transport is initialized, the #initialize method accepts an optional parameter named session_idle_timeout. In vulnerable versions (pre-0.23.0), this parameter defaulted to nil. Consequently, when instantiating the transport without explicitly setting a timeout, the class bypassed the execution of #start_reaper_thread, which is responsible for managing background context cleanup.

When an unauthenticated client connects to the transport layer, it initiates a handshake by sending an HTTP POST request to register its capabilities via the initialize method. Upon processing this command, the server executes #handle_initialization, generating a random UUID to track the client session. This newly generated context is stored inside the @sessions hash map. Each ServerSession instance acts as a heap-allocated memory structure containing request tracking arrays, operational parameters, and outbound messaging queues.

Because the server lacked any constraints on the size or growth of the @sessions hash map, the storage mechanism was structurally unbounded. A client could complete the initial handshake, obtain a session identifier via the HTTP response header Mcp-Session-Id, and subsequently drop the underlying TCP connection. The application server, unaware of the client's abrupt disconnection, retains the corresponding ServerSession context in memory indefinitely. Lacking an active background scavenger process, the server's heap memory increases continuously with each subsequent request.

A comparative review of the transport source code highlights the missing configuration checks and the remediation steps applied in version 0.23.0. In the vulnerable version, the constructor is defined without secure defaults, permitting the @session_idle_timeout variable to remain unassigned. The patch introduces a structured sentinel object UNSET_IDLE_TIMEOUT to safely determine whether the user intended to bypass timeouts or if they simply relied on safe SDK defaults.

The following code block highlights the vulnerable constructor in the StreamableHTTPTransport class:

# VULNERABLE: Code path from versions < 0.23.0
def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil)
  super(server)
  @sessions = {}
  @mutex = Mutex.new
  @stateless = stateless
  @enable_json_response = enable_json_response
  @session_idle_timeout = session_idle_timeout
  @pending_responses = {}
  # ...
  # If session_idle_timeout is nil (default), the reaper thread never spawns.
  start_reaper_thread if @session_idle_timeout
end

In contrast, the secure implementation in version 0.23.0 sets up a default timeout threshold of 1800 seconds (30 minutes) and establishes a hard upper cap of 10,000 sessions. It also validates inputs and prevents state allocations in stateless environments. The patched constructor implements these limits as follows:

# PATCHED: Code path from version 0.23.0
DEFAULT_SESSION_IDLE_TIMEOUT = 1800
DEFAULT_MAX_SESSIONS = 10_000
 
UNSET_IDLE_TIMEOUT = Object.new.freeze
private_constant :UNSET_IDLE_TIMEOUT
 
def initialize(
  server,
  stateless: false,
  enable_json_response: false,
  session_idle_timeout: UNSET_IDLE_TIMEOUT,
  max_sessions: DEFAULT_MAX_SESSIONS,
  # ...
)
  super(server)
  @sessions = {}
  @mutex = Mutex.new
  @stateless = stateless
  # ...
  # Resolve default timeout safely
  @session_idle_timeout = if session_idle_timeout.equal?(UNSET_IDLE_TIMEOUT)
    stateless ? nil : DEFAULT_SESSION_IDLE_TIMEOUT
  else
    session_idle_timeout
  end
 
  if @session_idle_timeout
    if @stateless
      raise ArgumentError, 'session_idle_timeout is not supported in stateless mode.'
    else
      start_reaper_thread # Proactively spawns background thread by default
    end
  end
 
  @max_sessions = stateless ? nil : max_sessions
end

Furthermore, the patch implements a proactive, inline-scavenging check during request routing. When a new connection arrives and the active session count matches or exceeds @max_sessions, the server scans the map, deletes expired slots synchronously, and updates the state before evaluating if it must drop the incoming request. This prevents immediate denial of service responses when expired sessions can be readily recycled.

Exploitation of CVE-2026-67430 is straightforward and requires no prior authentication or specific network privileges. An attacker only needs network routing to the target TCP port where the stateful MCP server is listening. The exploitation cycle consists of initiating multiple concurrent HTTP POST requests containing a valid JSON-RPC 2.0 initialize command. Because the target does not validate client authenticity before storing session context, every request results in immediate allocation.

To optimize the exploitation flow, the attacking script transmits the initial JSON payload and terminates the TCP socket immediately upon receiving the initial response. By avoiding the subsequent connection steps, such as setting up the SSE stream or executing queries, the attacker minimizes their own client-side memory footprint and connection state. The server, conversely, is forced to maintain the allocated state objects, leading to an asymmetric resource load.

Testing conducted during the vulnerability's initial discovery proved that a single client stream can generate approximately 50,000 sessions in 26.6 seconds. Under this workload, the memory utilization of the host process increases rapidly. Once system RAM limits are exceeded, the kernel invokes the Out-of-Memory killer, abruptly terminating the Ruby application server. This results in complete denial of service for all dependent clients.

The impact of successful exploitation is a complete Denial of Service (DoS) of the host application, disrupting context exchange for integrated LLM systems and clients. Because the MCP SDK often serves as an inline middleware or wrapper for real-time model interaction pipelines, a service crash halts all active operational queries and blocks future system requests. This can cause wider application failures if parent frameworks fail to handle endpoint unavailability gracefully.

The vulnerability has been evaluated with a CVSS v3.1 score of 5.3 (Medium), reflecting the unauthenticated, remote nature of the exploit balanced against the temporary impact on availability. Because exploitation does not compromise the confidentiality or integrity of host filesystems or execution environments, the base metric ratings remain isolated to the Availability vector. The EPSS score of 0.00291 indicates a low probability of exploitation, but because the MCP SDK is increasingly deployed across internet-facing integrations, the systemic exposure risk is notable.

A detailed review of the attack surface reveals that while the application-level constraints prevent immediate OOM events, secondary risk factors remain. For example, the 503 HTTP status code returned upon reaching the 10,000 session cap is still vulnerable to pool starvation. A slow, distributed attack can cycle requests slowly enough to bypass the 30-minute idle threshold, maintaining the session table at capacity with minimal throughput. Consequently, application availability can be compromised even without crashing the service.

Remediation of CVE-2026-67430 requires upgrading the mcp gem to version 0.23.0 or later. This release enforces secure-by-default options for stateful configurations, ensuring that timeouts and max session boundaries are actively managed. If immediate upgrades are not feasible, developers must configure explicit parameters on instances of StreamableHTTPTransport to mitigate the unbounded growth of the @sessions variable.

When declaring the transport instance in code, developers should explicitly pass a reasonable idle timeout value and set a conservative limit on the number of concurrent sessions. Passing session_idle_timeout: 900 forces the background reaper thread to spawn and prune inactive contexts every 15 minutes. Additionally, setting a hard session cap using max_sessions stops memory growth from exceeding acceptable bounds. For architectures that do not require state persistence between client requests, setting stateless: true is recommended as it bypasses session allocation entirely.

To establish defensive-in-depth protection, the application server must be placed behind a reverse proxy capable of enforcing rate-limiting at the network layer. This configuration mitigates both application-level OOM vectors and session pool starvation attempts. By restricting the rate of incoming connections from individual IP addresses and imposing maximum request payload limits, the proxy absorbs traffic surges and shields the vulnerable Ruby runtime from direct abuse.