MCPStore.nl

Published:

Official MCP reference servers reach 2.0: fetch now blocks internal addresses, and that may affect your setup

In short: the MCP project released v1.0.0 of its reference servers (fetch, filesystem, git, memory and others) on 11 October 2026 and v2.0.0 on 19 October. The key change: since version 2026.10.10, mcp-server-fetch refuses requests to internal and cloud metadata addresses by default, fixing SSRF flaw CVE-2026-104120. Version 2.0 supports the 28 July 2026 specification and requires Node 24 for the TypeScript servers.

The reference servers in the modelcontextprotocol/servers repository are example implementations maintained by the MCP project itself. They are meant as teaching material: the README explicitly calls them "educational examples" rather than production-ready solutions. In practice, fetch, filesystem and git show up in countless Claude Desktop, Cursor and VS Code configurations, often unpinned via uvx or npx -y. If that is how you run them, you get these new versions automatically the next time the server starts.

What exactly was released?

The project shipped two releases in quick succession.

Both releases also include filesystem-server fixes around roots, the directories a client grants the server access to. One of them revokes access when a roots update leaves no valid directory.

Which security issue was fixed in fetch?

The fetch server retrieves a web page and hands it to the model as text. Up to and including 2026.8.18, it followed redirects without checking where they led. A URL supplied by the model, or a redirect from an ordinary public site, could therefore end up at 127.0.0.1, internal network addresses or a cloud environment's metadata endpoint (169.254.169.254), which often hands out temporary credentials. That is server-side request forgery (SSRF), the same pattern we covered in our article on protocol pivoting.

The flaw was assigned CVE-2026-104120 on 2 October (by VulDB; CVSS 3.1 score 7.3). The CVE record lists versions up to 2026.6.4, but the guard only arrived in 2026.10.10, so the releases in between lacked it too. In the fix pull request (#5033), the maintainers show a redirect through a public site retrieving a secret from a local test server before the fix, and being refused after it.

Since 2026.10.10, the server resolves the hostname on every request, every redirect hop and the robots.txt fetch, and refuses anything that is not publicly routable. A new --allow-private-ips flag turns the guard off. It lives in the host configuration, so the model cannot switch it off itself. The README is candid about the limits: it does not protect against DNS rebinding between the check and the connection, and hostnames only a proxy can resolve are not checked.

Why should IT teams care?

For two reasons that pull in opposite directions. First, anyone running an older, pinned fetch version on a machine with access to internal systems or a cloud environment has a known flaw. Second, anyone who does not pin now gets new behaviour silently, and it can break existing workflows. An agent that used fetch to read an internal wiki, a local dev server or an intranet page now gets an error. And a filesystem or memory server launched via npx -y on a machine with Node older than 24 is no longer running on a supported version.

Our advice

(1) Search the MCP configurations across your organisation (Claude Desktop, Cursor, VS Code, internal agents) for mcp-server-fetch and the @modelcontextprotocol/server-* packages. (2) Pin a version instead of always pulling the latest: fetch ≥ 2026.10.10, preferably 2026.10.19 or 2.0.0 after testing. (3) Do not enable --allow-private-ips by default to fix a broken workflow. If an agent genuinely needs an internal source, give it a dedicated server with a short allowlist of addresses. (4) Treat reference servers as what they are: examples. Production use calls for a server with an owner, an update policy and network segmentation. More in MCP security and trusted MCP sources.

What does this release say about the MCP project?

Our take: the releases show the project taking its own example code more seriously. The maintainers first wrote test suites that explicitly flagged known bugs, then fixed those bugs, and only then migrated to the new SDK. The downside is the timeline. The SSRF issue was public knowledge: on 8 July a researcher asked in a public issue whether three security reports filed on 5 June had been seen, and that issue is still open. For organisations the lesson matches the SDK advisories from earlier this month: don't wait for an advisory; keep track of which MCP components you run and update them actively.

Sources

Frequently asked questions

Which mcp-server-fetch version is safe from CVE-2026-104120?

Version 2026.10.10 or later. From that version on, the server refuses requests and redirects to private, loopback, link-local and cloud metadata addresses by default. The CVE record lists versions up to 2026.6.4, but 2026.7.10 and 2026.8.18 lack the guard as well. The latest version is 2026.10.19.

My agent can no longer fetch internal pages. What now?

That is the new default. Adding --allow-private-ips to the server configuration turns the guard off, but removes the SSRF protection too. If an agent genuinely needs internal sources, use a separate server that only allows the specific internal addresses it needs.

Are the MCP reference servers suitable for production?

Not according to the MCP project itself: the README calls them example implementations, not production-ready solutions. If you use them anyway, pin a version, assign an owner and restrict their network and file access.

Last updated: