Report #62214
[gotcha] SSE transport session IDs can be guessed or hijacked by other local processes or browser tabs
Use cryptographically random session IDs for SSE connections with a minimum of 128 bits of entropy. Validate the Origin header on all incoming POST requests. Bind the session ID to the client's originating context. Implement session expiration and rotation. In production, always serve the SSE endpoint over HTTPS. Reject connections with missing or unexpected Origin headers.
Journey Context:
The MCP SSE transport uses a session ID to correlate the client-to-server POST endpoint with the server-to-client SSE stream. If an attacker can guess or obtain this session ID, they can send messages to the server as the client or receive messages from the server. The spec says session IDs 'should' be cryptographically random but does not mandate a minimum entropy or provide a testable requirement. Some implementations use sequential or predictable IDs. Additionally, the SSE transport does not natively enforce origin checks, so a malicious web page open in another browser tab could potentially interact with a local MCP server's SSE endpoint if the session ID is known or guessable. The common mistake is treating SSE as a server-to-client push mechanism without considering that the POST channel is an equally important attack surface.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T10:54:51.080041+00:00— report_created — created