MCP 官方参考服务器 2.1.0：修复 8 个安全漏洞

Model Context Protocol 官方参考服务器仓库于 2026 年 10 月 25 日发布 v2.1.0，一次修掉分布在 filesystem、everything、fetch 三个参考服务器里的八个漏洞，并给出每个包的受影响版本区间与修复版本；其中文件系统服务器的写入重定向问题在 Windows 上仍只是部分修复。

这次发布的是什么

Model Context Protocol（MCP）的官方参考服务器仓库 modelcontextprotocol/servers 在北京时间 2026 年 10 月 25 日凌晨发布 v2.1.0，版本的正文标题直接写的是「Security fixes」。这不是一个新服务器，而是一次集中的安全修复：一次性处理分布在 filesystem、everything、fetch 三个参考实现里的八个漏洞，并逐个给出受影响版本区间与对应的修复版本。

按仓库给出的清单，需要动的是三个包：npm 上的 @modelcontextprotocol/server-filesystem 与 @modelcontextprotocol/server-everything 都升到 2.0.1，PyPI 上的 mcp-server-fetch 升到 2026.10.24。另外四个参考实现（server-memory 2.0.0、server-sequential-thinking 2.0.0、mcp-server-git 2026.10.19、mcp-server-time 2026.10.19）本版列在同一张清单里，但标记为未变更。

受影响面偏大的是 filesystem：它是把某个本地目录开放给模型的那类连接器，装过 MCP 客户端的人基本都用过；everything 与 fetch 则常作为联调样例与网页抓取入口出现。本版还顺带把仓库自身的 MCP TypeScript SDK 依赖升到 2.4.0、Node.js 适配器升到 2.1.2，属于底层依赖更新，不改对外用法。

可用性与限制

• 修复版本：filesystem 与 everything 在 npm 上要达到 2.0.1；mcp-server-fetch 在 PyPI 上要达到 2026.10.24。低于这些的包不受本次修复覆盖。
• 升级要手动指定：TypeScript 服务器在 1.0.0 时才从 2025.x / 2026.x 这类日期版本号切到语义化版本，包管理器会把 2.0.1 排在所有日期版本之后，不会主动提示升级。
• Windows 只修了一半：写入重定向问题在 Linux 与 macOS 上已拦住，Windows 上仍有残留暴露面，官方在对应的安全公告里说明了剩余风险与配置绕法。
• 受影响区间明确：filesystem 的受影响范围是 1.0.0 至 2.0.0 以及截至 2026.8.31 的日期版本；everything 还额外涵盖 2025.9.24 起的日期版本；fetch 的受影响范围是截至 2026.10.19 的版本。
• 获取方式：三个包都在各自的公开注册表发布，升级本身没有额外的授权步骤；是否需要重启宿主客户端取决于具体程序，以官方文档为准，费用与额度以官网为准。

主要功能

• 拦截被符号链接替换的父目录，写入不再越界
• 按实际使用的路径校验，不再忽略结尾空格或引号
• 修复符号链接检查被大小写变体绕过的回归
• 列举目录前先逐项校验，不再泄露目录外文件的大小与修改时间
• 让 HTTP 与 SSE 传输拒绝来自其它网页来源的请求
• 让地址检查与实际连接使用同一个主机名
• 按内嵌的 IPv4 判定 NAT64 地址，拦截内网目标
• 每次重定向之后重新检查 robots.txt

技术原理

八个漏洞里有一半以上属于同一类：检查时的路径与真正被使用的路径不是同一个东西。文件系统服务器的经典写法是「先判断有没有权限，再执行读写」，两步之间如果有人把中间某一级目录换成一个符号链接，那次检查的结论就作废了；本版的说法是「写入留在被检查过的那个目录里」，在 Linux 与 macOS 上把这条链路合上了。与之相邻的另外两个修复也是同一个思路：一是访问检查过去会剥掉结尾的引号或空白，而文件操作不会，于是名字多一个后缀的同级目录变得可达；二是在 macOS 这类不区分大小写的卷上，用别的字母大小写拼写同一个符号链接名就能绕过检查。

另三个修复转向网络侧。everything 服务器的 HTTP 与 SSE 传输过去允许任意网页来源调用，本版改成检查请求头里的来源标识，并停止返回通配的跨域响应头，于是用户打开的一个网页不再能直接调用服务端的工具并读回结果。fetch 服务器的两个修复则在处理域名：一是国际化域名存在多种书写形式，过去检查用的是一种形式、实际连接用的是另一种，可能被引导到内部地址；二是运行在 NAT64 地址段里的地址要按它内嵌的 IPv4 地址来判定，否则私有地址与本地回环地址不再被拦住。最后一个修复是把 robots.txt 的检查从「只查最初那个地址」改成「每次重定向后重新查」。

实际体验

可以按下面几步自查这次影响的覆盖面，全程不需要写脚本，用命令行就能确认：

第一步，先看自己装了什么。在你的 MCP 客户端配置里搜 filesystem、everything、fetch 三个名字，把出现的包名和版本抄下来；如果版本是 2025 或 2026 开头的日期串，对照上面的受影响区间判断。

第二步，核对注册表里的当前版本。在终端里看包信息，例如用 npm view 包名 dist-tags.latest 看 npm 上的口径，用 pip index versions 包名 看 PyPI 上的口径；本批写作时两个 filesystem 与 everything 的作用是 2.0.1，fetch 是 2026.10.24。

第三步，确认升级是否真的发生。日期版本不会被自动提示升级，所以要显式指定版本号安装；装完再跑一次第二步，如果看到的仍是旧的日期版本号，说明升级没有生效。

第四步，Windows 用户单独处理。写入路径这一个问题在 Windows 上没有完全解决，官方在对应公告里给了配置绕法；如果你在 Windows 上把敏感目录挂进了 filesystem，这一步要看完公告再决定怎么配，而不是升完级就算了。

项目地址与获取方式

仓库在 GitHub 的 modelcontextprotocol/servers，发布页是 2026-10-25 的 v2.1.0 条目，正文里包含完整的安全公告链接、版本对照表与致谢名单。包的分发走各自的官方注册表：TypeScript 服务器在 npm，Python 服务器在 PyPI。请通过官方注册表与官方仓库获取，避免安装来源不明的镜像或被二次打包的版本。

适合谁用

• 自建 MCP 对话客户端的开发者：把本地目录挂载给模型的那一类配置，是直接受影响的人群。
• 把 everything 当联调样例跑在同一个网络里的人：跨站调用打通之前只在演示环境用，也可能被同网的网页触发。
• 用 fetch 服务器抓外部网页的工作流：重定向与域名判定相关的两个修复会改变实际能抓到的范围。
• 只是调用第三方托管服务的人：升级动作在服务端，本地通常无需处理，看服务商公告即可。
• 短期不动环境的人：至少把受影响版本的清单记进待办，下一次动依赖时一并处理。

常见问题

我怎么知道现在用的版本在不在受影响区间里？

先把配置里的包名与版本抄出来，再对照发布正文里的那张表：filesystem 的受影响范围是 1.0.0 到 2.0.0 以及截至 2026.8.31 的日期版本，everything 的范围还包含 2025.9.24 起的日期版本，fetch 是截至 2026.10.19。落在区间内就该升级，落在区间外则不受本次修复涉及。

从日期版本升到 2.0.1，配置会被清掉吗？

本版的说明只涉及包版本与越界拦截行为的变化，没有提到配置文件格式调整。但因为日期版本号在包管理器里排在前面，必须显式指定版本号安装，装完建议重新核对一次实际解析到的版本，确认确实是 2.0.1 而不是被日期版本压住。

Windows 上还能继续用 filesystem 服务器吗？

能用，但要清楚边界：这条修复在 Linux 与 macOS 上合上了写入越界的链路，Windows 上只是部分生效，官方在对应的安全公告里说明了还剩哪些暴露面以及怎么通过配置规避。Windows 用户升级后应当继续读那份公告，把绕法按自己环境配好。

everything 只是演示服务器，也要升吗？

要看它跑在哪里。这次修的是 HTTP 与 SSE 传输对跨站请求的放行，如果它只在本机命令行里被客户端调用，风险有限；一旦监听在可被浏览器访问的地址上，用户打开一个网页就可能触发其中的工具。演示用途不等于没有网络面，判断依据是它是否监听了端口。

相关工具与内容

• MCP 参考服务器 1.0.0 版本说明
• FastMCP 4.1.2 与 4.1.3 安全版
• GitHub Copilot 用量指标统计自建技能与 MCP
• Claude Code 工具页
• Dify 工具页
• AI 编程
• AI 智能体