MCP Official Servers v2.1.0 Fix Eight Vulnerabilities: Path Traversal and SSRF Protections Upgraded

An Update Beyond the Version Number

If you use the official MCP file system, Everything, or fetch servers in your projects, this release named v2.1.0 deserves its own upgrade window. It adds no new tools or features — every change is about security: the three servers fix eight vulnerabilities in total, most of which concern path validation and network request boundaries. If exploited, an attacker could read or write directories outside the sandbox, or make the server access internal network addresses.

The fixes are spread across three packages: @modelcontextprotocol/server-filesystem and @modelcontextprotocol/server-everything are bumped to 2.0.1, while the Python-side mcp-server-fetch goes to 2026.10.24. The release notes were submitted by maintainer cliffhall and include acknowledgments for community reporters, indicating that most of these vulnerabilities came from proactive disclosure by external security researchers.

File System Server: Aligning Path Checks with Real Operations

The file system server is one of the most frequently used components in the MCP ecosystem, letting models read and write specified directories. Version 2.0.1 fixes four issues, with the core idea of eliminating the path discrepancy between "check time" and "use time."

Escape via Symlink Replacement

The most typical attack occurs between check and write: the server first verifies the target path is inside the allowed directory, then, before the actual write, an attacker replaces a parent directory with a symlink pointing outside. The targets of write_file, edit_file, create_directory, and move_file could then land outside the permitted scope. The new version implements consistency between write operations and directory checks on Linux and macOS. However, the release notes explicitly state that the fix on Windows is incomplete; the remaining exposure and workaround configuration are documented in GHSA-53mr-w429-c597, so teams deploying on Windows need to pay extra attention.

TOCTOU (Time-of-Check to Time-of-Use) is a classic race condition vulnerability. The pattern is: the program first performs a security check based on a path (e.g., confirming the target is inside an allowed directory), then performs the actual operation based on the same path string. If there is a time window between the two operations, an attacker can replace a component of the path (e.g., swap a parent directory for a symlink pointing outside) so that the actual access lands somewhere the check did not anticipate. The core defense is to bind the check and the operation to the same resolved, immutable object — for example, using openat2 with RESOLVE_BENEATH on Linux, or performing subsequent operations based on a file descriptor rather than a path after opening the file, thereby eliminating the possibility of the path being tampered with mid-way.

Trailing Quotes and Case Differences

Three other vulnerabilities are subtler. First, path checks strip trailing quotes or whitespace, but the actual file operations preserve them, so a sibling directory named "allowed directory name + quote suffix" could bypass the check (GHSA-7rgq-gccq-qphx). Second, symlink checks are case-insensitive, so on macOS's default case-insensitive volume, a different capitalization could pass the check — a regression introduced in version 2026.8.31 (GHSA-4gxg-m5jx-9j57). Third, list_directory_with_sizes reads each entry's size before performing any check, allowing symlinks inside the allowed directory to leak the size and modification time of external files (GHSA-hhwq-wxfx-cj7g).

Everything Server: Tightening Cross-Origin Requests

The Everything server is often used for testing and demos, but it also exposes real tools, including get-env, which reads environment variables. The issue fixed in 2.0.1: HTTP and SSE transports previously accepted requests from any web origin and returned Access-Control-Allow-Origin: *, meaning any webpage a user visited could call server tools and read the results (GHSA-mvf5-2qqv-rg3c).

The fix checks the Origin header and stops sending the wildcard CORS response header. For developers debugging MCP services in a browser environment, this change may break cross-origin calls that previously "happened to work"; you need to configure allowed origins according to your actual setup rather than relying on the default permissive behavior.

CORS (Cross-Origin Resource Sharing) is a relaxation mechanism for the same-origin policy enforced by browsers. By default, web scripts can only request resources from the same origin; if a server wants to allow other origins to access it, it must return an Access-Control-Allow-Origin header in the response. When that header is set to *, it means any origin is allowed to read the response content. For MCP servers running locally or on an internal network, wildcard CORS means any malicious webpage a user visits could send requests to it and read the returned tool execution results, resulting in cross-site data leakage. The correct approach is to validate the request's Origin header, return the appropriate Access-Control-Allow-Origin only for whitelisted origins, and avoid using wildcards in scenarios involving credentials.

fetch Server: Address Validation Consistent with the Actual Connection

Version 2026.10.24 of the Python package mcp-server-fetch addresses three network-request-related issues, again with the idea of making "the address being judged" the same as "the address being connected to."

In internationalized domain name (IDNA) scenarios, the server previously checked one domain form but connected to another, potentially reaching internal addresses (GHSA-v38p-wf49-hx2j). For NAT64 addresses, requests in the 64:ff9b::/96 range that encapsulate private, loopback, or link-local IPv4 addresses are now rejected, consistent with the handling of IPv4-mapped addresses (GHSA-66qx-2266-pmj6). In addition, the robots.txt check no longer applies only to the originally requested URL — it is re-checked after every redirect (GHSA-3jqg-r5pp-rmp2).

For teams building scraping agents, these three changes directly affect the effectiveness of SSRF protection, and explain why scraping tools need to strictly distinguish between hostnames at the resolution stage and at the connection stage.

SSRF (Server-Side Request Forgery) refers to an attacker inducing a server to make requests to unintended addresses, typically targeting internal services, cloud metadata endpoints (such as 169.254.169.254), or loopback addresses. The difficulty of defense lies in the inconsistency between address resolution and connection: the server may first check whether the hostname in the URL is safe, but by the time the actual connection is established, the DNS resolution result has changed (DNS rebinding), or the same address has multiple representations (IDNA internationalized domain names, IPv4-mapped IPv6, NAT64, etc.), thereby bypassing the check. The NAT64 prefix 64:ff9b::/96 can map IPv6 addresses to IPv4; without normalization, an attacker can use it to wrap private IPv4 addresses and evade IPv4-based filtering. Robust SSRF protection should validate at the level of the actual resolved IP and pin the connection to the verified address.

The Biggest Pitfall When Upgrading: Version Number Ordering

The most easily overlooked point of this release is the change in versioning scheme. The TypeScript servers switched from date versions (2025.x, 2026.x) to semantic versioning at 1.0.0, and package managers sort 2.0.1 below all 2025.x and 2026.x versions, so they will not recognize it as an upgradable version.

If you are still on a date version, you need to install explicitly, for example npm install @modelcontextprotocol/server-filesystem@2.0.1. The same applies to server-everything. The Python-side fetch server continues to use CalVer — this release is 2026.10.24 — and can be upgraded normally via PyPI.

Semantic versioning (SemVer) uses the format MAJOR.MINOR.PATCH, and its ordering rules compare numeric segments position by position, so 2.0.1 sorts below date versions (CalVer) such as 2026.10.19. When a package manager relies on SemVer ordering to determine "whether a new version exists," a package that switched from date versions to 2.x will not be considered an upgrade candidate, and npm outdated will not flag it either. CalVer (calendar versioning) is commonly used for projects strongly tied to time, with formats like YYYY.MM.DD; its advantage is an intuitive release cadence, but when mixed with SemVer, the ordering semantics conflict. When encountering such a versioning scheme migration, you typically need to complete the upgrade by explicitly specifying the version number, adjusting the dependency range, or using a dist-tag.

The Collaboration Signal Behind the Security Advisories

Judging from the acknowledgments in the release notes, these eight CVEs came from eight different reporters, covering areas such as path handling, cross-origin requests, and address classification. This dispersed sourcing shows that MCP servers have entered a phase of systematic auditing by the security community, rather than just feature iteration.

For users, this means two things: upgrade cadence should follow security advisories rather than feature releases; and since file system and scraping tools are inherently high-privilege components, even with fixes in place, they should be deployed with minimal directory permissions and network egress whitelists to reduce the actual impact surface when a vulnerability is triggered.

In this release, server-memory and server-sequential-thinking remain at 2.0.0, and mcp-server-git and mcp-server-time remain at 2026.10.19 — all unchanged.

One-line Summary

MCP servers v2.1.0 fix eight security vulnerabilities, and a versioning scheme switch requires explicit upgrades.

Paragraph Summary

The official MCP servers have released v2.1.0 with no new features — all changes are security fixes. Three packages fix eight vulnerabilities: server-filesystem and server-everything are bumped to 2.0.1, and the Python-side mcp-server-fetch to 2026.10.24. The file system server fixes path escapes via symlink replacement, trailing-quote bypasses, a check regression on case-insensitive volumes, and information disclosure in directory size listing, though the Windows fix is incomplete. The Everything server no longer returns a wildcard CORS header and validates Origin. The fetch server unifies address validation for IDNA, NAT64, and robots.txt after redirects. Note especially that the TypeScript servers have switched from date versions to semantic versioning, so package managers will not automatically suggest 2.0.1 — you must install it explicitly.