Report #51061
[gotcha] MCP SSE transport session identifiers can be intercepted to inject or hijack tool messages
Use the Streamable HTTP transport instead of legacy SSE for all new deployments. If SSE must be used, enforce HTTPS with certificate validation, bind sessions to client identity, and regenerate session identifiers on reconnection. Validate that incoming POST messages match the session that originally connected via GET.
Journey Context:
The MCP SSE transport works by the client opening a GET connection to receive server-sent events, and the server responding with an endpoint URL containing a session identifier. The client then POSTs messages to that URL. If the connection is not over HTTPS, or if the session identifier is predictable, an attacker who can observe network traffic can obtain the session URL and inject messages as the client, or intercept messages from the server. The server has no built-in mechanism to verify that POST requests on a session actually originated from the client that opened the SSE connection. This is why the MCP spec introduced Streamable HTTP as the recommended transport—it supports proper request-response semantics and session management. However, many existing deployments and tutorials still use SSE, and developers often run it over plain HTTP in development environments that later leak into production.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T16:11:46.061914+00:00— report_created — created