mcp-go DNS Rebinding / Missing Host Validation on Loopback MCP Servers

Technical Analysis

StreamableHTTPServer.ServeHTTP and SSEServer.ServeHTTP accepted any request arriving on a loopback socket without verifying that the Host header itself named a loopback address, and the SSE transport's default CORS policy permitted any origin. An attacker-controlled web page can rebind a DNS name it controls to 127.0.0.1 (classic DNS rebinding), causing the victim's browser to send same-origin requests that the browser believes are cross-origin but that the server treats as trusted local traffic. This lets a remote attacker, via a browser acting as an unwitting intermediary, invoke MCP tools and read resources exposed by the local server, crossing the trust boundary between 'localhost-only' and internet-reachable content without any authentication bypass beyond the missing Host check. The fix (server/http_localhost.go) rejects loopback-bound requests whose Host header is not a loopback name, closing the rebinding vector on both transports.

Affected Systems

mcp-go; protocols: MCP

Detection Signatures

• HTTP requests to loopback MCP server ports (commonly 3000, 8000-8100 range or custom) with non-loopback Host headers
• SSE/StreamableHTTP requests with Origin headers from unexpected/public domains
• Rapid DNS resolution changes for a low-TTL domain resolving alternately to public and 127.0.0.1/localhost
• MCP server logs showing tool invocations correlated with browser-originated User-Agent strings and no corresponding local client process
• Absence of Host header validation logic in server/streamable_http.go or server/sse.go for mcp-go versions < 0.56.0

Remediation Steps

1. 1

   Upgrade mcp-go

   Update to mcp-go v0.56.0 or later, which validates that loopback-bound requests carry a loopback Host header on both StreamableHTTP and SSE transports.

2. 2

   Restrict CORS on SSE transport

   Explicitly configure allowed origins for the SSE server rather than relying on defaults that permit any origin.

3. 3

   Bind to loopback with authentication

   Even for local-only MCP servers, require a shared secret, token, or mTLS for tool invocation rather than relying solely on network binding as an access control.

4. 4

   Network-level mitigation

   Use host firewall rules or a local reverse proxy that enforces Host/Origin validation independently of the application, as defense in depth.

5. 5

   Audit exposed tools

   Review which tools and resources are reachable via the loopback MCP server and ensure sensitive operations (file access, code execution, credentials) require explicit user confirmation.