DNS rebinding turns localhost MCP servers into a remote attack surface

What is this?

Over roughly seven months, a single class of vulnerability was disclosed against nearly every official Model Context Protocol (MCP) SDK and several MCP servers built on top of them. The root cause is the same in each case: an HTTP-based MCP server listening on localhost did not validate the incoming Host (or Origin) header, leaving it open to a DNS rebinding attack. The MCP specification has long flagged this — its transport security guidance states that “Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks” (MCP spec, 2025-06-18) — but the SDKs did not enforce it by default.

The disclosures, largely credited to researcher Jonathan Leitschuh, span the TypeScript SDK (CVE-2025-66414, Dec 2, 2025), the Java SDK (CVE-2026-35568, Apr 7, 2026), the Rust rmcp crate (CVE-2026-42559, Apr 29, 2026), plus the Python and Go SDKs. The most recent entry — CVE-2026-11624 in Google’s MCP Toolbox for Databases, published June 13, 2026 and rated CVSS 4.0 9.4 (Critical) — shows the pattern is still surfacing in production tooling (CIRCL Vulnerability-Lookup).

How it works

DNS rebinding is an old browser-network attack, repurposed here against the agent stack. The mechanics are well documented and require no novel exploit:

1. A developer runs an MCP server bound to localhost over Streamable HTTP or SSE — common for local agent tooling — usually without authentication.
2. The victim visits an attacker-controlled web page. The attacker’s domain first resolves to their own server, then is rebound to 127.0.0.1 (a very short TTL swap).
3. The victim’s browser, still treating the page as same-origin for the attacker’s hostname, now sends requests to the local MCP server. If the server only checks that a request arrived, and never checks which host name the browser thought it was talking to, it answers.

Because the browser cannot forge the real Host header sent to the rebound address, validating that header (against an allowlist such as localhost, 127.0.0.1, ::1) is what blocks the attack. Servers that skipped this check let a remote web page enumerate and invoke any exposed tool. The conceptual shape of the abused request:

# A request the browser is tricked into sending cross-origin (values illustrative)
POST /mcp HTTP/1.1
Host: attacker-rebound.example        # never checked by the vulnerable server
Content-Type: application/json
{ "method": "tools/call", "params": { "name": "[REDACTED_TOOL]", ... } }

Per the Rust advisory, the practical blast radius is large: an attacker can “enumerate and invoke any tool,” read resources and prompts, and “trigger side effects (file writes, shell execution, API calls)” — so for servers exposing filesystem, shell, or browser-control tools, this can escalate to arbitrary code execution on the developer’s machine.

Why it matters

MCP servers are quietly becoming the most privileged component in an agent deployment: they run with the user’s rights and broker access to real tools. A “localhost-only” bind feels safe, which is exactly why this class is dangerous — the loopback interface is not a security boundary against a browser the victim is already running. Any unauthenticated HTTP MCP server on a developer laptop is reachable by any website the developer happens to open.

The breadth is the story. This is not one vendor’s mistake but a specification-versus-implementation gap replicated across an entire ecosystem: the spec said MUST, the SDKs shipped insecure defaults (the TypeScript flaw is classified CWE-1188, Insecure Default Initialization), and downstream servers inherited the gap. The steady drumbeat from December 2025 through the Critical-rated Google Toolbox CVE on June 13, 2026 suggests more MCP servers carrying this pattern remain unpatched in the wild. Note that stdio transports are not affected — only HTTP/SSE servers.

Defenses

Upgrade to the patched SDK versions. TypeScript @modelcontextprotocol/sdk ≥ 1.24.0, Java mcp-core ≥ 1.0.0, Rust rmcp ≥ 1.4.0 (current 1.5.1), and the patched Python/Go releases. For Google’s MCP Toolbox, upgrade to ≥ 0.25.0, which adds --allowed-hosts/--allowed-origins flags (note both still default to * and only emit a startup warning, so set them explicitly).

Enforce Host/Origin allowlists. The fixes validate the Host header against a loopback allowlist (localhost, 127.0.0.1, ::1) and return HTTP 403 otherwise; the TypeScript SDK exposes a hostHeaderValidation() middleware. Turn this on; do not rely on the default in older builds.

Put a reverse proxy in front. Where you cannot upgrade, run the server behind nginx, Caddy, or HAProxy configured to reject any request whose Host/Origin is not an expected value. Frameworks that already enforce strict CORS/Origin validation (e.g. Spring AI) were not vulnerable.

Add authentication and avoid 0.0.0.0. Do not run unauthenticated HTTP MCP servers on shared interfaces. Bind to loopback only, require a token, and prefer stdio for purely local tooling.

Audit what your tools can do. Treat every locally exposed MCP tool as reachable from a browser until proven otherwise, and minimize high-impact tools (shell, unrestricted filesystem) on any HTTP-exposed server.

Status

Component	Identifier	Disclosed	Fixed in	Severity
Google MCP Toolbox for Databases	CVE-2026-11624	2026-06-13	0.25.0	CVSS 4.0 9.4 (Critical)
Rust SDK (rmcp)	CVE-2026-42559	2026-04-29	1.4.0	CVSS 3.1 8.8 (High)
Java SDK (mcp-core)	CVE-2026-35568	2026-04-07	1.0.0	CVSS 4.0 7.6 (High)
TypeScript SDK	CVE-2025-66414	2025-12-02	1.24.0	CVSS 4.0 7.6 (High)
Python / Go SDKs	GHSA-9h52-p55h-vw2f / GHSA-xw59-hvm2-8pj6	2025–2026	patched	High
Common weakness	CWE-346 (Origin Validation Error) / CWE-1188	—	—	—
Not affected	stdio transports; strict-CORS frameworks (e.g. Spring AI)	—	—	—