MCP服务器套件v2.2.0发布：CA证书更新与多项安全加固

MCP服务器套件v2.2.0发布

Model Context Protocol（MCP）官方服务器套件迎来 v2.2.0 版本。这次更新的主线并非新功能，而是一次围绕 CA 证书信任链的安全响应，同时顺带修复了文件系统、网络抓取、Git 操作等多个服务器中长期存在的边界问题。对于在生产环境中运行这些 MCP 服务器的开发者来说，这是一次需要认真对待的升级。

一次由 CA 私钥泄露触发的连锁更新

事情的起点在 2026 年 10 月 20 日：证书机构 eMudhra 披露，其八张中间 CA 证书的私钥可以从公开证书中恢复出来。这意味着任何依赖这些根证书的信任链都可能被滥用。第二天，Node.js 发布安全版本，更新了内置的 CA 证书包，并顺带修复了若干高危运行时 CVE。10 月 23 日，Python 的 certifi 包发布 2026.10.23 版本，移除了 eMudhra 的 emSign Root CA - C1 与 emSign ECC Root CA - C3 两个根证书。

MCP 服务器套件在 10 月 28 日跟进发布 v2.2.0，核心动作就是让各个服务器站在更新后的信任基础上。发布说明中逐一说明了每种服务器的暴露面：TypeScript 服务器本身不携带 CA 证书，完全依赖所运行的 Node.js 运行时做证书校验；其中只有 server-everything 会发起出站 HTTPS 请求（通过 gzip-file-as-resource 工具），server-filesystem、server-memory 和 server-sequential-thinking 则完全不建立网络连接。Python 侧的 mcp-server-fetch 走 httpx，用 certifi 包做 HTTPS 校验，从 PyPI 安装时会解析到当前版本的 certifi；仓库里的 Dockerfile 也在此次发布中把锁定文件推进到 certifi 2026.10.23。mcp-server-git 和 mcp-server-time 同样不发起网络连接。

这种“按暴露面分类说明”的写法值得注意：它没有笼统地要求所有人升级，而是明确指出哪些组件存在实际风险、哪些只是理论关联。

中间 CA 与信任链：在 PKI 体系中，根 CA 位于信任链顶端，浏览器和运行时内置的根证书列表是信任的最终锚点。中间 CA 由根 CA 签发，用于实际签发终端实体证书（如网站证书）。如果中间 CA 的私钥被恢复或泄露，攻击者就能用它签发出被信任链认可的任何域名证书，而无需攻破根 CA。eMudhra 事件的关键在于“私钥可从公开证书中恢复”——这通常暗示签发时存在熵不足或参数生成缺陷，属于比单纯私钥泄露更隐蔽的失效模式。对客户端而言，唯一的止血手段就是从信任库中移除对应根证书，代价是依赖该根的所有合法站点同时失效。这也是为什么更新必须在 Node.js、certifi 这类信任库层完成，而不是在单个应用里打补丁。

certifi 与系统证书库的区别：Python 生态中，certifi 是一个自带 Mozilla CA 捆绑包的独立包，httpx、requests 等库默认用它做 TLS 校验，而不是操作系统证书库。因此 Python 服务的信任根更新节奏由 certifi 的发布决定，与系统 update-ca-certificates 无关。这也解释了为什么虚拟环境会“冻结”旧信任根：环境创建时解析到的 certifi 版本被写入锁定，后续不会自动跟随上游。

运行时升级：TypeScript 服务器用户需要自查

对于通过 npm（npx 或全局安装）运行 TypeScript 服务器的用户，发布说明给出了明确要求：请运行 Node.js 24.22.1 或 26.12.1 及更高版本，并用 node --version 确认。原因在于这些包的 engines 字段接受任意 Node.js 24，所以 npm 不会因为运行时版本偏旧而给出警告——这意味着一个未打补丁的 Node.js 可以悄无声息地继续运行。

对于已经存在环境中运行 mcp-server-fetch 的用户，情况类似：10 月 23 日之前创建的环境会保留旧版 certifi，需要用 uvx --refresh mcp-server-fetch 刷新，或执行 pip install -U certifi 更新。

这类“依赖由用户环境提供”的设计在 MCP 服务器中很常见，它降低了发布包体积，却把补丁责任转移给了使用者。v2.2.0 的说明实际上是在提醒：安全更新不会自动到达你的机器。

SemVer 范围与 engines 字段的局限：npm 包的 engines 字段只是声明兼容范围，默认并不会强制拦截安装，除非启用 engine-strict。当某个包声明 node: ">=24" 时，24.x 的任何补丁版本都满足条件，包括尚未修复 CA 包或运行时 CVE 的旧补丁版。这就是发布说明要求“24.22.1 或 26.12.1 及以上”却无法由 npm 自动保障的原因：版本约束表达的是 API 兼容性，而非安全基线。实践中可借助 npm config set engine-strict true、在 CI 中显式断言 node --version，或用 .nvmrc/volta 固定补丁版本，把安全基线从“建议”变成“门禁”。

各服务器的问题修复清单

抛开证书话题，这次发布包含的修复数量相当可观，多数集中在输入边界和异常路径上。

server-everything 2.1.0

该包修复了 elicitation 请求对表单自身字段的汇总逻辑；gzip-file-as-resource 在收到 HTTP 错误响应时会正确失败，并且每一跳都拒绝非公开地址；get-env 默认对类似凭据的值做掩码处理；get-tiny-image 的 PNG 中损坏的 iCCP 数据块被移除，同时修正了 get-resource-links 中若干误导性命名与 JSDoc 头注释。

server-filesystem 2.1.0

文件系统服务器的修复最为密集：允许目录的大小写变体在文件系统确认后可以接受；tail 不再把末尾换行算作一行，head 也把 CRLF 行统一规范为 LF；get_file_info 新增硬链接计数报告并补充了硬链接文档；realpath 与 readdir 的等待以及递归遍历都加上了边界；重试一次失败的 realpath，避免丢失根目录；客户端 Root 的声明形式与 realpath 形式均可接受；跨文件系统移动文件时通过 EXDEV 走复制路径；覆盖身份比较改用 BigInt stats，并带 Windows 无设备号回退；10 万条目遍历测试加上了显式超时。

EXDEV 与跨文件系统移动：POSIX 的 rename(2) 只能在同一文件系统内原子完成，跨挂载点（如从 /tmp 的 tmpfs 移到磁盘，或跨 Docker volume）会返回 EXDEV。正确做法是退化为“复制到目标临时文件 + fsync + rename + 删除源”，在无法保证原子性的前提下至少保证不产生半写文件。同理，realpath 在符号链接或挂载点变动时可能瞬时失败，重试一次是应对竞态的常见缓解手段；而用 BigInt 版 stat 比较身份，是为了避免 inode 与设备号在 32 位精度下被截断导致的误判。

server-memory 2.0.1

存储记录在多次写入之间会保留未建模字段；memory.json 迁移失败时停止启动，而不是带着不一致状态继续运行。

mcp-server-fetch 2026.10.28

robots.txt 返回 5xx 时拒绝自主抓取；拒绝 IPv4 兼容的 IPv6 地址（::/96）；在 beautifulsoup4 4.13 下把空树页面报告为无法简化；无 Content-Type 的响应只有在正文确实是 HTML 时才按 HTML 处理；新增 --no-readability-js 选项，让内容提取不经过 Node.js；按 HTML 声明的字符集解码页面；要求 readabilipy 0.3.0，使非 cp1252 页面在 Windows 上也能提取；恢复被 hydration 隐藏的服务端渲染内容；声明 beautifulsoup4 依赖，并在原始前缀中标注缺失的 Content-Type。

SSRF 防护与地址分类：抓取类服务器天然是 SSRF 的入口。仅检查字面量 IP 不够，因为 IPv4 兼容的 IPv6 地址（::/96，如 ::127.0.0.1）可绕过基于 IPv4 字符串的过滤；此外还需处理十进制/八进制写法、DNS 重绑定，以及 HTTP 重定向的“每一跳”复查——只在首次请求时校验，攻击者可用 302 跳到内网。发布说明中“每一跳都拒绝非公开地址”正是这一原则的落地。robots.txt 返回 5xx 时拒绝自主抓取，则属于失败即关闭（fail-closed）策略：服务器错误不代表允许抓取，宁可放弃也不越界。

mcp-server-git 2026.10.28

文档明确说明：不带 --repository 时，所有可达仓库都在作用范围内；在 detached HEAD 上以及从 commit-ish 基点创建分支；非 ASCII 路径按原样打印，无法解码的 diff 字节被替换；修复 GHSA-w766-5x43-whvw。

mcp-server-time 2026.10.28

Docker 镜像中的 LOCAL_TIMEZONE 改为在运行时展开。

社区贡献与发布流程的调整

发布说明用了整整一节感谢社区。@ShieldPi1 报告了 GHSA-w766-5x43-whvw，@alemuenchen 报告了递归遍历的边界问题（#4162），@DrDexter6000 与 @morozow 报告了与 SSR 内容回退相关的问题（#3878）。还有大量贡献者的 PR 被关闭、改动由维护者重建，并在对应 issue 上给予署名——这源于仓库“用 issue 而非 PR”的策略。

CI 侧也有变化：被取代的 dispatched 运行不再发布 pending 状态；Claude 工作流只对可信作者启动；新增的 alert sweep 会跟踪尚无补丁版本的 advisory。

对于使用 MCP 服务器的团队，v2.2.0 的升级清单可以概括为：确认 Node.js 版本、刷新 certifi、留意 filesystem 与 fetch 在异常输入下的行为变化。证书事件本身已经过去，但依赖用户环境提供信任根的架构意味着，下一次类似披露仍会以同样的方式传导到每个部署点。