GitHub Security Advisory: GHSA-qvqr-5cv7-wh35
Package: mcp (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-384: Session Fixation, CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 0.9.1
Patched in: 0.9.2

Summary: MCP Ruby SDK: Insufficient Session Binding Allows SSE Stream Hijacking via Session ID Replay

Details:
### Summary

The Ruby SDK's [streamable_http_transport.rb](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/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](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/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*