MCP DNS Rebinding Flaws Expose Gaps in Streamable HTTP Servers

Three implementations, one missing check

The Model Context Protocol (MCP) has a security rule for its Streamable HTTP transport that is easy to state. A server must check where a request came from before acting on it. Over the past several months, at least three separate implementations have been found skipping that step. The result is the same kind of exposure in each case. A web page the user happens to visit can reach a supposedly local MCP server and operate it.

The Rust case is the most fully documented. Before version 1.4.0, the rmcp crate's Streamable HTTP server transport never validated the incoming Host header. 1 Because of that, a malicious public website could use DNS rebinding to send authenticated requests to an MCP server on the victim's loopback or private-network interface. 1 The maintainers say this violates the MCP specification's transport security guidance. They fixed it in PR #764, which shipped in 1.4.0. They also note that the stdio and child-process transports were never affected. 1

The Ruby SDK's advisory, GHSA-rjr6-rcgv-9m7m, published July 7, 2026, describes an even more complete gap. The Rack-mountable StreamableHTTPTransport in the mcp gem handled every JSON-RPC request without reading the Host or Origin header. 2 It had no allowlist for hosts or origins and no rebinding guard of any kind. 2 Any loopback or LAN port bound by such a server was therefore reachable from whatever sites the user's browser loaded. 2

The third case is a public GitHub issue against Google's MCP Toolbox. The reporter says the toolbox does not validate the Origin header by default. That breaks a MUST-level requirement found in both the 2025-06-18 and 2025-11-25 MCP specifications. 3 The issue also argues that the project's README tells users to set up their connection in a way that is vulnerable out of the box. 3

How the attack works

DNS rebinding is an old technique, and the advisories describe it in nearly the same terms. An attacker hosts a page on a domain they control. Once the browser has loaded it, they change that domain's DNS record to point at 127.0.0.1 or a private address. 2 The browser still believes it is talking to the attacker's origin, so it lets the page's scripts send requests to the local service. 23

If the service never checks Host or Origin, it cannot tell these requests apart from legitimate ones. With MCP, the consequences go well beyond leaking data. According to the rmcp advisory, an attacker could list and call every tool the server exposes. They could also read resources, prompts, and session state, and trigger side effects such as file writes, shell commands, or API calls. 1 The only limit is what tools the server offers. 1 The Ruby advisory likewise describes tool invocation followed by theft of the output. 2

The specification already covers this. It says servers must validate Origin on all incoming connections and must return HTTP 403 when the header is present but invalid. 3 The Ruby advisory calls the attack "the standard browser-driven local-service attack" that the guidance exists to prevent. 2

Why it keeps happening

The overlap between these reports matters more than any one of them. The projects are written in Rust, Ruby, and Go-adjacent Google tooling, and some are maintained by the MCP project itself. Yet they reached the same blind spot independently. In my view, this is not a one-off coding mistake. It looks like a structural gap between what the spec requires and what SDK defaults actually ship.

The MCP roadmap supports that reading. It places "HTTP-Native Transport Unification and Hardening" second among its priority areas. 4 It notes that the 2026-07-28 release turned remote MCP servers into ordinary HTTP workloads that increasingly depend on headers and status codes to carry transport-level information. 4 The roadmap also admits that SDKs maintain two transport pipelines and that protocol metadata is now duplicated across HTTP headers and message fields that servers must cross-validate. 4 Header validation is precisely the kind of work that slips through in that arrangement.

One proposed fix is to run Streamable HTTP over stdin/stdout for local servers, possibly as HTTP/2 over stdio. The goal is to keep the security and lifecycle guarantees of a subprocess. 4 A server reached that way never opens a network port, so it gives a rebinding attack nothing to target. That fits rmcp's note that its stdio transport was unaffected. 1 Separately, the roadmap's identity work, including DPoP and agent delegation, addresses who is calling a server. That is a related question but not the same one as where a request originated. 4

What to take from it

The practical advice is simple. Upgrade rmcp to 1.4.0 or later. 1 Review any Ruby mcp gem deployment against the published advisory. 2 Do not assume a local HTTP-bound MCP server is protected just because it listens on localhost. 3

The larger lesson is that a MUST in a specification protects no one unless SDKs enforce it by default. Until host and origin allowlists become standard behavior rather than optional settings, developers should treat every local MCP server on HTTP as reachable from the open web.