Fetch has a guard now. It is still not a firewall.
An October 11 MCP release blocks non-public destinations by default. DNS rebinding and proxy-only names remain outside that guarantee.
Facts checked October 12, 2026
An October 11 MCP release blocks non-public destinations by default. DNS rebinding and proxy-only names remain outside that guarantee. PR #5033
The request starts somewhere else
A URL arrives in an AI conversation. It looks like a request to read a public page. The network connection, however, comes from the machine running the fetch server, not from the person typing the URL. That distinction is the whole problem: the tool borrows the host's network reach. My reading of the new MCP reference-server release is that a useful default has changed, but the machine still needs a boundary of its own.
What shipped, and what did not become a promise
The official release record, published October 11 at 02:40 UTC, lists mcp-server-fetch 2026.10.10 among seven published reference packages. Its change list includes pull request #5033: refuse private, loopback and metadata addresses by default. The pull request was merged October 5. This is a package release, not a claim that every MCP deployment now has this guard. An older installed process does not acquire a new policy because a release page exists.
Where the check sits
The maintainers describe an HTTP request hook that resolves the host before each request. If any resolved address is non-public, the request is refused. The same check covers robots.txt, the page request and each redirect hop, on both the tool and prompt paths. A public first URL is therefore not a free pass for a later redirect to an internal address. The documented --allow-private-ips startup flag disables the guard. It is host configuration, not an argument the model can add to one fetch call.
Two holes in a simple sentence
The source names two limits. The hook resolves a hostname, then the HTTP connection resolves it again. DNS rebinding can give different answers between those steps: checking a public address is not the same as connecting to that address. Also, a hostname the server cannot resolve is passed to the transport. A proxy may resolve that name elsewhere. The server's check cannot certify a destination it never resolved. These are documented limits, not failures I reproduced. I did not install or execute the package.
Analysis: put the guarantee at the connection
My conclusion is narrower than "safe browsing for agents": this guard removes important default paths to non-public addresses, while a separate egress policy must constrain the actual connection. In a deployment review I would ask which resolver, proxy and network rule decide the final destination. A URL allowlist alone does not answer that question. Nor does a read-only tool label: reading can send a request containing a sensitive query, and the response can contain hostile instructions. Treat returned text as evidence, never as permission to change the task.
A reproducible acceptance plan, not a test report
Before rollout, use a disposable host without secrets and a public endpoint you control. Exercise a normal public page, a direct loopback URL, a public redirect to loopback, and a hostname resolved only by the configured proxy. Record the exact package version, flags, proxy and requested destination. Expect the documented refusals where the guard can resolve the address; do not describe the proxy-only case as protected. For DNS rebinding, review or test the connector boundary separately. Do not probe someone else's internal service or a real metadata endpoint.
What I would keep in the release ticket
The useful artifact is a small ledger: observed server version; whether the bypass flag is absent; evidence for each redirect refusal; the network policy at the connection; and the two remaining limits. Keep "maintainers report" separate from "we observed". The pull request reports protocol tests and an Inspector experiment, but says no LLM client was tested there. That is valuable source evidence with a stated boundary. A version number can name a release; it cannot replace the deployment evidence.
Illustrative decision ledger, not executable security code
request → resolve host → refuse non-public answer
↓
HTTP connection resolves again
↓
actual destination needs egress policy