DNS Rebinding and Local MCP Servers

DNS rebinding is an attack that lets a malicious website talk to a server running on your own computer. If that server is a local MCP server using HTTP, the website can list its tools and call them. It all happens through your browser, without you noticing.

The MCP specification names this risk in its transport rules. The Streamable HTTP transport page says that without Origin checks, localhost binding and authentication, "attackers could use DNS rebinding to interact with local MCP servers from remote websites."

This is not theoretical. As of October 2026, the official TypeScript, Python, Go, Java, Ruby and Rust SDKs have each published a DNS rebinding advisory. This page explains how the attack works and what to do. Sources were checked on 28 October 2026.

How DNS rebinding works

Browsers block a page on one site from reading responses from another site. This is the same-origin policy. It is based on domain names, not IP addresses.

An attacker controls a domain, say evil.example. Its DNS first points at the attacker's real server. The page loads, then the attacker switches the DNS record to 127.0.0.1. The browser still thinks it is talking to evil.example. In fact, its requests now land on a server on your machine.

If that local server does not check where requests come from, it answers. For an MCP server, that can mean listing tools, reading resources, or calling a tool that writes files or sends messages.

The Python SDK advisory describes the result plainly. A malicious website could "invoke tools or access resources" on a local server on the user's behalf.

An illustrative example

This scenario is illustrative, not a real incident.

A marketing analyst runs a local MCP server that connects their AI assistant to a company database. The developer who set it up chose HTTP on port 8000 with no login, because "it is only on my laptop."

The analyst opens a link to a blog post. The page quietly runs a DNS rebinding script in the background. After a minute, it reaches localhost:8000, lists the server's tools, and calls the one that runs SQL queries. It sends the results to the attacker's server.

The analyst sees a normal blog post the whole time.

Real advisories

All of these were checked on 28 October 2026.

The TypeScript and Python advisories were published on 2 December 2025. Both say the SDK "does not enable DNS rebinding protection by default for HTTP-based servers." Both apply only to servers on localhost, without authentication, using HTTP transports.

The MCP Inspector case was a developer tool, not a production server. Oligo Security's write-up showed a web page could reach the Inspector's proxy and run commands. The fix added a session token and Origin and Host validation.

The dbt-mcp advisory shows the data at stake. Its local OAuth helper returned access and refresh tokens to any caller, including a DNS rebinding page.

The NVD keyword search for this topic returned 13 CVEs when we ran it. They include the Go, Java, Ruby and Rust SDKs and several popular servers.

Who is at risk

• Developers running local HTTP MCP servers for testing, especially with older SDK versions.
• Business users who installed a local server that listens on a port rather than using stdio.
• Teams using local OAuth helpers that briefly run a web server during sign-in.
• Anyone browsing the web on the same machine. The attack only needs you to visit a page.

How to detect it

• Check which MCP servers on a machine listen on a TCP port. On macOS or Linux, lsof -i -P | grep LISTEN shows them.
• Check the SDK version in each server's dependency file against the fixed versions above.
• Look in server logs for requests with an unexpected Host or Origin header.
• Run a quick test. Send a request with Origin: https://example.com. A protected server should return 403.

How to reduce the risk

Server side

The Streamable HTTP spec lists three rules:

1. Servers MUST validate the Origin header on all incoming connections. An invalid Origin MUST get HTTP 403 Forbidden.
2. When running locally, servers SHOULD bind only to 127.0.0.1, not 0.0.0.0.
3. Servers SHOULD implement proper authentication for all connections.

In practice:

• Update the SDK. The TypeScript advisory says createMcpExpressApp() now enables protection by default on localhost. Custom Express setups should add the exported hostHeaderValidation() middleware.
• Python users on FastMCP get protection by default from 1.23.0 when bound to localhost. (In SDK v2 that class is renamed MCPServer.) Low-level transports need TransportSecuritySettings configured.
• Prefer stdio. The best practices page recommends stdio "to limit access to just the MCP client."
• If HTTP is required, require an authorization token or use Unix domain sockets with restricted access.

Client side

• Prefer stdio connections for local servers when the server offers both.
• Warn users when a local server config points at an HTTP port.

Organization side

• Keep an inventory of local MCP servers on staff machines. Unapproved ones are what OWASP calls shadow MCP servers.
• Set a minimum SDK version policy for internal servers.
• Consider sandboxing local MCP servers so a compromised one cannot reach much.

What the spec says

The transport page makes Origin validation a MUST. Binding to localhost and authentication are SHOULD. The best practices page lists DNS rebinding as one of three main ways a local MCP server is compromised, next to malicious startup commands and malicious packages.

DNS rebinding also appears in the spec's SSRF section, as a way to beat IP checks. See SSRF in MCP for that side of the problem.

Next step

List every local MCP server your team runs and check its transport and SDK version. Our guide to exposed local MCP servers covers the related risk of servers open to your whole network. If you build servers, our MCP development team ships stdio-first designs with Origin checks on any HTTP endpoint.

Frequently asked questions