Bump mcp from 0.8.0 to 0.9.2 (GHSA-qvqr-5cv7-wh35)

[Copilot]

mcp 0.8.0 allows SSE stream hijacking: a second GET with the same session ID silently overwrites the stored stream, redirecting all subsequent server-sent data to the attacker. Fixed in 0.9.2, which rejects duplicate SSE connections with HTTP 409.

Changes

• Gemfile.lock: bumped mcp 0.8.0 → 0.9.2. Both versions share the same single runtime dependency (json-schema >= 4.1), making this a clean version-only swap.

Reachability

Not reachable. mcp enters the dependency graph only as a transitive dep of simplecov-mcp (a test coverage formatter). No MCP server or StreamableHTTPTransport is instantiated anywhere in this codebase. This update clears the scanner rather than closing an active attack surface.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>MCP Ruby SDK: Insufficient Session Binding Allows SSE Stream Hijacking via Session ID Replay</alert_title>
<alert_description>### Summary

The Ruby SDK's streamable_http_transport.rb implementation contains a session hijacking vulnerability. An attacker who obtains a valid session ID can completely hijack the victim's Server-Sent Events (SSE) stream and intercept all real-time data.

Details

Root Cause
The StreamableHTTPTransport implementation stores only one SSE stream object per session ID and lacks:

• Session-to-user identity binding
• Ownership validation when establishing SSE connections
• Protection against multiple simultaneous connections to the same session

PoC

Vulnerable Code

File: streamable_http_transport.rb - L336-L339:

def store_stream_for_session(session_id, stream)
  @mutex.synchronize do
    if @sessions[session_id]
      @sessions[session_id][:stream] = stream  # OVERWRITES existing stream
    else
      stream.close
    end
  end
end

Attack Scenario

Step 1: Legitimate Session Establishment

POST / (initialize) → receives session_id: "abc123"
GET / with Mcp-Session-Id: abc123 → SSE stream connected

Step 2: Session ID Compromise

• An attacker obtains the session ID through various means (out of scope for this analysis)

Step 3: Stream Hijacking

GET / with Mcp-Session-Id: abc123 
@sessions["abc123"][:stream] = attacker_stream `# Victim's stream is REPLACED (silently disconnected)

Step 4: Data Interception

• ALL subsequent tool responses/notifications go to the attacker
• The legitimate user receives no data and has no indication of the hijacking

Technical Details

The vulnerability happens:

Client 1 connects (GET request)

proc do |stream1|  # ← Rack server provides stream1 for client 1
 @sessions[session_id][:stream] = stream1  # Stored
end

Client 2 connects with SAME session ID (Attack!)

proc do |stream2|  # ← Rack provides stream2 for client 2
 @sessions[session_id][:stream] = stream2  # REPLACES stream1!
end

Now when the server sends notifications:

@sessions[session_id][:stream].write(data)  # Goes to stream2 (attacker!)
# stream1 (victim) receives nothing

Comparison: Python SDK Protection

The Python SDK prevents this vulnerability by rejecting duplicate SSE connections:

Refer: https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamable_http.py#L680-L685

if GET_STREAM_KEY in self._request_streams:  # pragma: no cover
            response = self._create_error_response(
                "Conflict: Only one SSE stream is allowed per session",
                HTTPStatus.CONFLICT,
            )

When a duplicate connection attempt is detected, the Python SDK returns an HTTP 409 Conflict error, protecting the existing connection.

Recommended Mitigations
For SDK Maintainers

• Implement User Binding: All SDKs should bind session IDs to authenticated user identities where possible. Currently only, go-sdk and csharp-sdk do user binding.
• Ruby SDK: Prevent Duplicate Connections: Implement checks to reject or handle multiple simultaneous connections to the same session
• Improve Documentation: Provide clear guidance on secure session management implementation for SDK consumers

Steps To Reproduce:

Please find attached two python client files demonstrating the attack

Terminal 1:
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

Terminal 2:

python3 legitimate_client_ruby_server.py

What happens:

• The client connects and prints the session ID
• Press Enter to start the SSE stream
• Notifications start appearing every 3 seconds as the client makes a tool call

Terminal 3 (while the legitimate client is running):

python3 attacker_client_ruby_server.py <SESSION_ID>

Replace <SESSION_ID> with the ID from Terminal 2.

What happens immediately:

• Terminal 2 (Legitimate): Stops receiving notifications, shows disconnect message
• Terminal 3 (Attacker): Starts receiving ALL the tool call responses

Impact

While the absence of user binding may not pose immediate risks if session IDs are not used to store sensitive data or state, the fundamental purpose of session IDs is to maintain stateful connections. If the SDK or its consumers utilize session IDs for sensitive operations without proper user binding controls, this creates a potential security vulnerability. For example: In the case of the Ruby ...

• Resolves rubyforgood/casa alert add driving fields to downloadable report for admins #305