fetch: private-address guard bypass via IDNA hostnames (check and connect resolve different names)

For an internationalized hostname the hook and the connection resolve different names:

• httpx stores the host IDNA 2008 encoded (URL.raw_host, e.g. xn--fa-hia.attacker.example) and connects to that name.
• URL.host, which the hook passes to getaddrinfo, is the decoded Unicode form (faß.attacker.example). CPython's socket.getaddrinfo encodes a Unicode name with the built-in idna codec, which is IDNA 2003 and maps ß to ss, so the hook looks up fass.attacker.example.

The domain owner points fass. at any public address and xn--fa-hia. at an internal one. The hook approves the public answer and httpx connects to the internal address. There is no timing involved, so this is separate from the documented DNS-rebinding limit.

The same mismatch also reaches the documented proxy-only branch (L130-L133, which skips the check when the hook's lookup fails) for a name the server does resolve: if the IDNA 2003 name does not exist, the hook skips the check, and httpx resolves the IDNA 2008 name itself and connects directly, with no proxy configured. The fix below covers both.

Both apply to the URL the model passes to the fetch tool and to every redirect hop, since all of them go through the same hook. ß is one example; final sigma ς gives the same split (σοφος is xn--0xaajbq for the connector and xn--0xaakcn for the hook). Characters that httpx's IDNA 2008 encoder rejects (ZWJ/ZWNJ, compatibility forms such as Ⅳ or fi) cannot be used.

Suggested fix: resolve and check the exact name the connection uses, request.url.raw_host.decode("ascii") instead of request.url.host, and treat a resolution failure as a refusal unless a proxy is configured. Doing the check inside the transport (resolve once, connect to the checked address) would also close the documented DNS-rebinding gap.

Proof of concept

Reproduction:

1. In a DNS zone you control, create fass.<zone> with any public A record and xn--fa-hia.<zone> with an internal A record (I used 127.0.0.1, standing in for an internal or metadata endpoint). Optionally leave fass.nx.<zone> undefined and create xn--fa-hia.nx.<zone> -> 127.0.0.1 to see the proxy-only branch reached without a proxy.
2. Run an HTTP service on the internal address (I used a stub on 127.0.0.1:80 that returns a canary JSON for /latest/meta-data/...).
3. Start mcp-server-fetch 2026.10.10 as python -m mcp_server_fetch with no arguments (no --allow-private-ips, no --proxy-url) and no relevant environment variables, so the guard is on. Client: the MCP Python SDK 1.30.0 (ClientSession.call_tool) over stdio.
4. Call the fetch tool with http://xn--fa-hia.<zone>/latest/meta-data/... (or the Unicode form http://faß.<zone>/...). The internal service's response comes back as the tool result. The same request with a plain name resolving to 127.0.0.1, or with http://127.0.0.1/..., is refused by the guard.

My run, in one disposable python:3.12-slim container with a toy DNS server on 127.0.0.1:53 and the stub on 127.0.0.1:80 (nothing outside the container contacted after installing the package). Versions: Python 3.12.15, mcp-server-fetch 2026.10.10, httpx 0.28.1, idna 3.20, mcp 1.30.0. The real server was driven over stdio with the MCP Python client, calling fetch with raw: true:

The internal service logged the requests with Host: xn--fa-hia.attacker.test and Host: xn--fa-hia.nx.attacker.test, including the robots.txt check, which takes the same path.

Root cause in three lines:

import httpx
u = httpx.URL("http://xn--fa-hia.attacker.test/")
print(u.host, u.raw_host, u.host.encode("idna"))
# faß.attacker.test b'xn--fa-hia.attacker.test' b'fass.attacker.test'

I can share the full container script (DNS server, stub service, MCP client) if it helps.

Impact

Server-side request forgery (CWE-918) through a bypass of the default egress guard. Affected: anyone running mcp-server-fetch 2026.10.10 with default settings, typically as a tool for an AI agent. The guard exists to stop a model-supplied URL, for example one planted by prompt injection in fetched content, from reaching loopback services, RFC 1918 hosts and cloud metadata endpoints from the machine running the server. With this bypass an attacker who controls any domain gets that access back, and the response is returned to the model, so it can be read or passed on.

Limits: the attacker needs the model to fetch an attacker URL (prompt injection or a user request); what is reachable depends on where the server runs; I tested a loopback service standing in for a metadata endpoint.