MCP 一批发 8 个漏洞修复，包管理器却把 2.0.1 当降级：聚合网关要查 3 件事

8 个漏洞、3 个服务端，一张表说清

10 月 25 日，模型上下文协议（MCP）官方参考实现 servers 仓库发布 v2.1.0，一次性修复 8 个安全漏洞，分布在这 3 个服务端里。官方 release 写明了受影响区间：@modelcontextprotocol/server-filesystem 覆盖 1.0.0 到 2.0.0 及 2026.8.31 之前的日期版本，@modelcontextprotocol/server-everything 区间相同，mcp-server-fetch 覆盖 2026.10.19 及更早；修复目标分别是 2.0.1 与 2026.10.24。memory、sequential-thinking、git、time 四个参考服务端本次没有改动。

最核心的问题是"检查一条路径，写另一条路径"

filesystem 服务端 4 个漏洞同型。最典型的是一个 TOCTOU 竞态：写新文件时，路径校验器走 ENOENT 兜底分支，只校验父目录后原样返回调用方给的路径；同用户下的另一个进程可以在校验与写入的间隙把父目录换成符号链接，write_file、edit_file、create_directory 与 move_file 就会落在允许目录之外。edit_file 的读改写循环让竞态窗口最长，是最坏情形。该修复覆盖 Linux 与 macOS，Windows 上只修了一部分，公告单独交代了仍暴露什么、如何配置绕过。

风险分最高的，反而是"演示服务端"

8 个漏洞里 CVSS 分最高的是 6.5，不在使用面最广的 filesystem，而在演示与测试用的 everything 服务端：它的 HTTP 与 SSE 传输完全不检查 Origin 头，响应直接回 Access-Control-Allow-Origin: *，任何用户打开的网页都能调用服务端工具（包括 get-env 读取环境变量）并读回结果。真正危险的是演示配置常被原样复制进生产环境，2026.8.31 到 2.0.0 都带着这个洞。修复后跨源请求会被直接拒绝。

fetch 服务端 3 个问题都围绕"公网/内网边界"：国际化主机名校验与连接使用不同形式、可能摸到内网地址；NAT64 前缀 64:ff9b::/96 包裹私有 IPv4 地址时被误判为公网；robots.txt 只在首次请求检查，重定向之后不再复查。3 处均已修复。

升级陷阱：包管理器认为 2.0.1 是降级

这是本次发布最值得传播的一点：TypeScript 服务端在 1.0.0 时从日期版本切换到语义版本，包管理器会把 2.0.1 排在所有 2025.x、2026.x 日期版本之下，不会把它当作升级项推荐。也就是说，装了 2026.8.31 的团队在升级面板里会看到"没有可用更新"，很容易误以为漏洞已关——实际上 8 个洞全在身上。唯一出口是显式安装 2.0.1；Python 侧 mcp-server-fetch 仍按日期版本发布，正常升级到 2026.10.24 即可。

聚合网关该查什么：3 件事

对在同一网关下聚合多套工具链的团队，这次发布是一次版本治理的压力测试。一，审计工具链里的 MCP 服务端，把钉在日期版本或 2.0.0 线上的找出来，显式升到 2.0.1；二，检查集群里有没有走 HTTP/SSE 的实例，改 stdio 或配源白名单——6.5 分是 8 个里唯一能被纯网页触发的；三，这是继 CVE-2025-53109、53110 之后同一校验区域的第三轮修复，说明 allowedDirectories 这条"边界"被反复侵蚀过。私有化部署验收时，建议把判据定为"校验的路径就是实际写入的路径"，而不是版本号够不够新。

我们的观察：补丁本身是便宜动作，贵的是版本纪律——发布渠道一换轨，修复就从升级队列里静默消失了。对多租户的聚合方，建议把这类"版本陷阱"写进例行巡检清单，安全发布一出就照单跑一遍。

来源：GitHub modelcontextprotocol/servers v2.1.0 发布说明与安全公告（2026-10-25 00:03 UTC）、dev.to、Clauding、newreleases.io 等公开报道交叉核对。