MCP servers v2.1.0 fixes eight vulnerabilities in server-filesystem, server-everything and mcp-server-fetch

Overnight on October 25 the MCP project shipped version 2.1.0 of its reference servers, along with eight security advisories. Three packages are affected: @modelcontextprotocol/server-filesystem and @modelcontextprotocol/server-everything move to 2.0.1, mcp-server-fetch to 2026.10.24. The other four servers in the collection are unchanged.

Four of the eight holes are rated medium, four low. That reads harmless until you look at what these servers do. The filesystem server hands a model read and write access to folders on your machine, and that is exactly where the bugs were.

Four ways out of the allowed directory

All four filesystem bugs come down to the same shape: the server checks one path and then uses another.

The first is a classic race. Between the permission check and the actual write, a parent directory could be swapped for a symlink, and write_file, edit_file, create_directory or the destination of move_file would land outside the allowed directories. Fixed on Linux and macOS. On Windows only partly—advisory GHSA-53mr-w429-c597 spells out what is still exposed and how to configure around it.

The second is simpler still. The check stripped a trailing quote or whitespace that the file operation kept, so a sibling directory named like an allowed one plus that suffix was reachable. Two more round it out: a symlink check that let a different letter case through, which is enough on macOS’s default volumes, and list_directory_with_sizes, which leaked the size and modification time of files outside the allowed directory.

The everything server, which exists mainly for trying things out, had a different problem. Its HTTP and SSE transports sent Access-Control-Allow-Origin: * and never checked the Origin header, so any web page the user happened to visit could call its tools, get-env among them, and read the results.

The three fetch-server bugs all concern its guard against requests to internal addresses: internationalized host names were checked in one form and connected to in another, NAT64 addresses in 64:ff9b::/96 counted as public even when they carry a private IPv4 address, and robots.txt was only checked for the URL first requested, not after each redirect.

The upgrade trap

Here is the practical part. With 1.0.0 the TypeScript servers moved from date versions to semantic versions. Package managers therefore sort 2.0.1 below every 2025.x and 2026.x version and will not offer it as an update. So anyone who installed 2026.8.31 at some point sees nothing to upgrade and assumes the holes are closed.

The way out is to name the version explicitly:

npm install @modelcontextprotocol/server-filesystem@2.0.1
npm install @modelcontextprotocol/server-everything@2.0.1

The Python server stays on date versions, so a normal upgrade to 2026.10.24 is enough there.

The reference servers are what everyone else copies

Anthropic handed MCP to the Agentic AI Foundation in 2025, and I wrote about the Agent Skills donation to the same foundation two days ago. These reference servers are not just another repository, then. They are the template anyone writing their own MCP server reaches for. Copy the filesystem server’s path validation and you copy the bug with it.

The pattern in all four filesystem cases is the same: a gap between checking and using. That is not a typo-level mistake, it is the hardest class of security bug there is, and it hit a tool that gives a language model write access to real folders. The one that bothers me most is the everything server leaking environment variables to any web page, because that server mostly runs on people’s machines for testing—which is precisely why nobody looked at what it opens up.

Four ways out of the allowed directory

The upgrade trap

The reference servers are what everyone else copies

Sources