CVE-2026-81092 in mcp-go
Summary
by MITRE • 08/27/2026
mcp-go accepted requests on its HTTP transports without checking the Host header. StreamableHTTPServer.ServeHTTP in server/streamable_http.go and SSEServer.ServeHTTP in server/sse.go served any request arriving over a loopback connection regardless of the host it named, and the SSE transport's cross-origin default allowed any origin. A page in a browser could therefore point a name it controlled at the loopback address and reach a server listening there, invoking tools and reading resources that the server exposed on the assumption that only local software could connect. No release before 0.56.0 validated the header on either transport; 0.56.0 adds server/http_localhost.go, which rejects a loopback-bound request carrying a host that is not a loopback name, and wires it into both transports.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in mcp-go represents a critical failure in network boundary enforcement within the Model Context Protocol implementation. Specifically, the HTTP transport layers failed to validate the Host header against the expected local context before processing incoming requests. This flaw existed in two primary components: StreamableHTTPServer.ServeHTTP located in server/streamable_http.go and SSEServer.ServeHTTP located in server/sse.go. These functions were designed to serve any request arriving over a loopback connection, such as 127.0.0.1 or localhost, without verifying that the Host header matched an expected local address. This oversight created a significant security gap where the application assumed that connectivity via the loopback interface implied trustworthiness and authorized access from local software only.
The operational impact of this vulnerability is severe due to its potential for cross-origin exploitation through browser-based attacks. Because the SSE transport had a default configuration allowing any origin, an attacker could craft a malicious web page hosted on a remote domain or even a controlled local domain that points at the loopback address where mcp-go was listening. By doing so, the attacker's webpage could send HTTP requests to the server as if they were originating from a trusted local application. This allowed the invocation of tools and reading of sensitive resources exposed by the MCP server under the false assumption that only legitimate local processes would interact with it. The lack of Host header validation meant there was no mechanism to distinguish between a request genuinely initiated by a local client and one spoofed via cross-origin requests from an external context, effectively bypassing same-origin policy protections intended to isolate web content.
This issue aligns closely with CWE-284 Improper Access Control, as the system failed to restrict access based on identity or privilege levels derived from network metadata. Furthermore, it relates to CWE-346 Origin Validation Error because the application did not properly validate the origin of incoming requests against a whitelist of trusted sources. In terms of MITRE ATT&CK framework tactics, this vulnerability facilitates Initial Access and potentially Privilege Escalation if the MCP server runs with elevated privileges or has access to sensitive local resources that are normally protected by network isolation assumptions. The attack vector is classified as Local Network because it requires the victim user to interact with a malicious webpage while the vulnerable service is running on localhost, making it particularly dangerous in environments where users frequently browse untrusted sites while development servers are active.
The remediation for this vulnerability was implemented in version 0.56.0 of mcp-go through the introduction of server/http_localhost.go. This new component enforces strict validation by rejecting any loopback-bound request that carries a Host header not corresponding to a recognized loopback name, such as localhost or specific IP variants like 127.0.0.1 and ::1. The fix ensures that both the StreamableHTTPServer and SSEServer transports adhere to this policy, thereby closing the gap where external origins could masquerade as local clients. Organizations running versions prior to 0.56.0 are advised to upgrade immediately to mitigate the risk of unauthorized tool invocation and data exfiltration via browser-based attacks. Additionally, until an upgrade is performed, administrators should consider restricting network access to the MCP server ports or ensuring that no sensitive services are exposed on loopback interfaces accessible from untrusted web contexts.