MCP's Reference Servers Patch Eight Flaws in v2.1.0, but npm Won't Offer the Fix to Date-Versioned Installs

The Model Context Protocol project has fixed eight vulnerabilities in three of its reference servers, and many users won’t be told to upgrade. Release v2.1.0 of the modelcontextprotocol/servers repository went out on October 25, 2026 (UTC), together with eight GitHub security advisories. It ships @modelcontextprotocol/server-filesystem 2.0.1 and @modelcontextprotocol/server-everything 2.0.1 on npm, plus mcp-server-fetch 2026.10.24 on PyPI. The catch is the version numbers. The TypeScript servers switched from date-based versions such as 2026.8.31 to semantic versions in 1.0.0, so npm treats 2.0.1 as older than any 2025.x or 2026.x release. The advisories warn that package managers won’t offer it as an upgrade and Dependabot won’t open a pull request for it.

The filesystem server’s single promise, in its own description, is that it only works within the directories it is given, and the fetch server says it refuses private and cloud-metadata addresses by default. Every one of the eight advisories is about a way around one of those promises. No CVE numbers have been assigned to any of the eight yet, and one fix, for a write race in the filesystem server, is only partial on Windows.

Four ways out of the allowed folder

Four of the eight fixes cover the filesystem server, whose whole job is to keep an agent inside the directories it was given. Each closes a different gap between the path that was checked and the path that was used.

The most practical is a check/use mismatch (GHSA-7rgq-gccq-qphx, CVSS 4.2). The server’s path normaliser strips a trailing quote or whitespace character before the allow-list check, but the file operation uses the original string. A request for /allowed/proj' passes as /allowed/proj and then reads or writes a real sibling directory named proj'.

A second advisory (GHSA-4gxg-m5jx-9j57, CVSS 5.3) is a regression introduced in 2026.8.31. On a case-insensitive volume, which is the default on macOS and Windows, spelling a symlink’s name in a different letter case skips the symlink check, so new files can be created wherever that link points. The July release, 2026.7.10, refused such requests.

The third is a race (GHSA-53mr-w429-c597). When creating a new file, the server checked the parent directory and then wrote to the original path. A local process that swapped the parent for a symlink in between could redirect write_file, edit_file, create_directory or a move_file destination outside the sandbox. The fourth, rated low, lets list_directory_with_sizes leak the size of a file outside the allowed area through a symlink.

Windows still has a gap

The race fix is incomplete on Windows, and the advisory says so. On Linux and macOS, 2.0.1 anchors each write to the directory it checked. Node.js on Windows resolves every file operation from a path string rather than a directory handle, so a directory swapped for a junction, which needs no special privilege to create, can still redirect writes. The project’s guidance until a native fix lands (tracked as issue #5260) is not to configure an allowed directory that another user or an untrusted local process can write to.

A web page could read every secret

The fix with the highest CVSS 3.1 score (GHSA-mvf5-2qqv-rg3c, 6.5) is in server-everything, a test server that exercises every MCP feature. Its HTTP and SSE transports sent Access-Control-Allow-Origin: *, bound to all interfaces and required no authentication. It also includes a get-env tool that returns the whole process environment. According to the reporter, any web page open in a developer’s browser could complete the MCP handshake with a locally running copy, call get-env and read every API key in the environment. Version 2.0.1 adds an Origin check. The advisory adds that releases before 2025.9.24 didn’t send the permissive header but checked neither Origin nor Host, which left them open to DNS rebinding. The new Origin check closes that as well.

Fetch’s new SSRF guard had holes

Two of the three fetch fixes target a private-address guard added in 2026.10.10 to block requests to internal addresses and cloud metadata endpoints. In one (GHSA-v38p-wf49-hx2j, CVSS 4.0 score 6.3), the guard and the HTTP client resolved different forms of an internationalised host name. The guard looked up one name, the client connected to another, and a domain owner could point the second at an internal address. In the other, the guard treated the NAT64 prefix 64:ff9b::/96 as public, so on IPv6-only networks with NAT64 an address wrapping 169.254.169.254 could reach the metadata service. A third, low-severity fix makes the server check robots.txt again after every redirect.

What to run

Anyone running these servers should pin the fixed versions explicitly: npm install @modelcontextprotocol/server-filesystem@2.0.1, the same for server-everything, and mcp-server-fetch 2026.10.24 or later from PyPI. Client configurations that pin a date-based version for npx need editing by hand. The memory, sequential-thinking, git and time servers are unchanged.