DNS rebinding

How DNS rebinding works

A browser lets a script read answers only from its own origin. The browser compares names, not IP addresses. DNS rebinding uses that weak point.

The steps, after MITRE CAPEC-275 and NCC Group (2018):

1. The victim opens a page on a domain of the attacker.
2. The DNS server of the attacker gives the address of its web server, with a very short TTL.
3. The script of the page waits for the DNS record to expire.
4. The browser asks DNS again. The attacker then gives an internal address, such as 127.0.0.1.
5. The script sends requests to “its own” domain. They go to the local service, and the script reads the answers.

Why DNS rebinding is a risk for AI tools

Many AI tools operate an HTTP server on the computer of the user, frequently with no password. DNS rebinding lets a web page that the user opens send requests to that server.

An MCP server can hold keys to mail, files or a database. A hostile page that gets to the server can use those tools as the user.

In practice: AI tools open to DNS rebinding

Software	What the attacker could do	Fixed in
Ollama, CVE-2024-28224 (NCC Group, April 2024)	Full use of the Ollama API, and data from files on the host	v0.1.29
MCP TypeScript SDK, CVE-2025-66414 (December 2025)	Use tools and read resources of a local MCP server as the user	1.24.0
MCP Python SDK, CVE-2025-66416 (December 2025)	The same, for FastMCP servers on HTTP	1.23.0

NCC Group found that rebinding against Ollama “can happen in as little as 3 seconds once connected to a malicious web server”.

The attack is not new. Jackson and colleagues at Stanford (ACM CCS 2007) put the cost below $100 for 100,000 IP addresses. They also showed that DNS pinning, the classic browser defence, did not operate in the browsers of 2007.

5 methods to stop DNS rebinding on a local AI server

The server must do the defence. Do not trust the browser or the network to do it.

1. Check the Host header. Accept only known values, such as 127.0.0.1:3000 and localhost:3000 (NCC Group). The MCP TypeScript SDK gives hostHeaderValidation() for this.
2. Check the Origin header. The Model Context Protocol (MCP) specification (2025-06-18) says servers on Streamable HTTP “MUST validate the Origin header on all incoming connections”.
3. Use authentication, also on localhost. NCC Group and the MCP specification say this.
4. Listen on 127.0.0.1, not 0.0.0.0. This stops other computers. It does not stop the browser on the same computer. Use it with steps 1 to 3.
5. Use stdio for local MCP servers. The two 2025 MCP SDK advisories say the stdio transport is not affected.

Upgrade the MCP SDKs. In TypeScript SDK 1.24.0, servers made with createMcpExpressApp() have the protection on by default on localhost. In the Python SDK, set TransportSecuritySettings.

What does not stop DNS rebinding

• DNS pinning in the browser. Jackson and colleagues showed that it did not operate correctly in 2007. MITRE says IP pinning breaks some legitimate sites.
• DNS filters for private addresses. NCC Group says they “should not be relied upon as a primary defense”. Its Singularity tool got around some filters with a localhost CNAME record.
• One IP check in a URL filter. NLTK checked the IP of one DNS answer, then connected with a second answer. The advisory says “The validated IP is never the one connected to” (CVE-2026-12075, fixed in 3.10.0). This is the server side request forgery type of the attack. A filter must connect to the IP that it checked.
• A browser permission prompt alone. Chrome 142 asks the user before a public site sends requests to a local or loopback address (Local Network Access). The Chrome post does not name DNS rebinding, and the user can click Allow.

Questions and answers

Is an MCP server on stdio open to DNS rebinding?

No. With stdio, the client starts the MCP server as a subprocess. There is no HTTP port for a web page. The 2025 advisories for the MCP TypeScript and Python SDKs say that the stdio transport is not affected.

Does a local service on 127.0.0.1 stop DNS rebinding?

No. DNS rebinding uses the browser of the victim. The browser is on the same computer and can send requests to 127.0.0.1. A Host or Origin check and authentication stop the browser.

How is DNS rebinding related to SSRF?

In an SSRF attack, the server, not a browser, makes the request. DNS rebinding defeats SSRF filters that check the IP of one DNS answer and then connect with a second answer. NLTK had this fault in its nltk.pathsec filter in versions 3.9.4 and earlier (CVE-2026-12075).