CVE-2026-34742: 
MinimOS vulnerability analysis and mitigation

CVE-2026-34742 is a DNS rebinding protection bypass vulnerability in the Model Context Protocol (MCP) Go SDK (github.com/modelcontextprotocol/go-sdk) affecting all versions prior to 1.4.0. The SDK does not enable DNS rebinding protection by default for HTTP-based servers using StreamableHTTPHandler or SSEHandler, allowing a malicious website to bypass same-origin policy restrictions and send unauthorized requests to a locally running MCP server. The vulnerability was published on March 30, 2026 (advisory) and April 2, 2026 (NVD), with a patch released in version 1.4.0. It carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 7.6 (High) (GitHub Advisory, MCP Go SDK Advisory).

The root cause is classified as CWE-1188 (Insecure Default Initialization of Resource): the MCP Go SDK's HTTP handlers (StreamableHTTPHandler and SSEHandler) did not validate the HTTP Host header against the connection's local address by default, leaving localhost-bound servers unprotected against DNS rebinding attacks. In a DNS rebinding attack, a malicious website first resolves its domain to an attacker-controlled IP, then re-resolves it to 127.0.0.1, causing the victim's browser to send cross-origin requests to the local MCP server with the attacker's domain in the Host header — effectively bypassing the browser's same-origin policy. The fix (commit 67bd3f2) uses http.LocalAddrContextKey to detect when a connection arrives via a loopback address and rejects requests whose Host header does not also resolve to a localhost value, returning HTTP 403 Forbidden. Servers using stdio transport are not affected (GitHub Advisory, Patch Commit).

Successful exploitation allows a malicious website to invoke tools or access resources exposed by a locally running MCP server on behalf of the victim user, without any authentication. This can result in high confidentiality and integrity impact — an attacker could read sensitive data managed by the MCP server (e.g., files, database contents, API responses) or trigger unauthorized actions through exposed MCP tools. Availability is not directly impacted. The attack scope is limited to the vulnerable system (no subsequent system impact), but the data exposure risk is significant given that MCP servers may have broad access to local resources and AI tooling (GitHub Advisory, MCP Go SDK Advisory).

There is no public proof-of-concept exploit or evidence of in-the-wild exploitation at this time (Feedly). The vulnerability requires user interaction (the victim must visit a malicious website) and specific preconditions: an HTTP-based MCP server must be running on localhost without authentication. The EPSS score is approximately 0.08% (9th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify a target running an HTTP-based MCP server (using StreamableHTTPHandler or SSEHandler) on localhost without authentication, using a version of github.com/modelcontextprotocol/go-sdk prior to 1.4.0.
2. Set up malicious website: Register a domain (e.g., attacker.com) and configure a DNS server to initially resolve it to an attacker-controlled IP address.
3. Lure victim: Trick the victim into visiting the attacker's website (e.g., via phishing or malvertising), where malicious JavaScript is loaded in the browser.
4. DNS rebinding: After the browser caches the initial DNS response, the attacker's DNS server changes the resolution of attacker.com to 127.0.0.1 (with a very short TTL). The browser's DNS cache expires and re-resolves the domain to localhost.
5. Send cross-origin requests: The malicious JavaScript now makes HTTP requests to http://attacker.com:<port> — which the browser routes to 127.0.0.1:<port> (the local MCP server) — with attacker.com in the Host header. Because the vulnerable SDK does not validate the Host header, the request is accepted.
6. Invoke MCP tools/resources: The attacker's JavaScript sends MCP protocol messages (e.g., initialize, tool invocation requests) to the local server, accessing resources or triggering actions on behalf of the victim (GitHub Advisory, Patch Commit).

• Network: Unexpected HTTP POST or GET requests to local MCP server endpoints (e.g., http://127.0.0.1:<port>/) with a non-localhost Host header (e.g., Host: attacker.com or Host: evil.com) in server access logs.
• Logs: MCP server access logs showing requests with Host headers containing external domain names rather than localhost, 127.0.0.1, or [::1]; unusual MCP tool invocations or resource access patterns not initiated by the local user.
• Network: Outbound connections from the local machine to unexpected external IPs shortly after MCP tool invocations, potentially indicating data exfiltration triggered via MCP tools.
• Process: Unexpected child processes or file system changes initiated by the MCP server process following anomalous HTTP requests.

The primary remediation is to upgrade to MCP Go SDK version 1.4.0 or later, which enables DNS rebinding protection by default for StreamableHTTPHandler and SSEHandler when binding to localhost — no code changes are required for existing servers (GitHub Release v1.4.0). As a temporary workaround for users who cannot upgrade immediately, implement authentication on all HTTP-based MCP servers or switch to stdio transport, which is not affected. If the protection must be disabled (e.g., for reverse proxy compatibility), set StreamableHTTPOptions.DisableLocalhostProtection: true only after understanding the security implications; alternatively, use the MCPGODEBUG=disablelocalhostprotection=1 environment variable (available until v1.6.0). Per MCP security best practices, running HTTP-based MCP servers locally without authentication is not recommended (GitHub Advisory).

The advisory was published by maciej-kisiel of the MCP Go SDK maintainer team on March 30, 2026, with credit to security researcher JLLeitschuh for identifying the issue (MCP Go SDK Advisory). The fix was contributed via PR #760 by pcarleton (with Claude AI assistance) and finalized by maciej-kisiel, reflecting the project's proactive approach to secure-by-default design. The release notes for v1.4.0 explicitly highlight the DNS rebinding protection as a notable behavior change, with a compatibility escape hatch (MCPGODEBUG) provided for users needing transition time (GitHub Release v1.4.0).