MCP 官方参考服务器 2.2.0：跟进 eMudhra 证书事件，逐个说明各服务器的受影响面

MCP 官方参考服务器仓库于 2026 年 10 月 28 日发布 v2.2.0。这不是功能更新，而是一次针对 eMudhra 中级 CA 私钥事件的自查与对齐发布：Node.js 在 10 月 21 日的安全版本中更新了内置 CA 证书，Python 的 certifi 在 2026.10.23 移除了两个 eMudhra 根证书，本次发布说明了七个参考服务器各自站在哪一边，以及使用者需要自己做什么。

这次发布的是什么

MCP（Model Context Protocol）官方参考服务器仓库在 2026 年 10 月 28 日发布了 v2.2.0。这不是一次功能更新，发布正文的第一节就叫「Node.js 运行时与 CA 证书更新」，是一次围绕上游证书事件的自查与对齐。

事件链条在正文里写得很清楚：2026 年 10 月 20 日，eMudhra 披露其八张中级 CA 证书的私钥可以从公开证书中恢复；10 月 21 日，Node.js 发布安全版本，更新内置 CA 证书以应对该事件，同时修复若干个无关的高危运行时漏洞；10 月 23 日，Python 的 certifi 2026.10.23 移除了 emSign Root CA - C1 与 emSign ECC Root CA - C3 两个 eMudhra 根证书。

这次发布做的事，是把这些上游变化映射到仓库里的七个参考服务器上，逐个说明谁受谁不受，以及使用者需要自己做什么。

可用性与限制

• 本次发布性质：安全对齐与自查发布，不是功能更新。
• TypeScript 服务器：不自带 CA 证书，依赖所运行的 Node.js 做证书校验，需自行升级运行时。
• 建议的 Node.js 版本：官方要求 24.22.1 或 26.12.1 及以上，可用 node --version 自查。
• 旧运行时不会被拦：包的 engines 字段接受任意 Node.js 24，npm 不会为打了补丁前的版本给出警告。
• Python 的 fetch 服务器：从 PyPI 安装时会解析到当前 certifi（2026.10.23 或更新）；仓库的 fetch Dockerfile 已在本次发布把锁文件移到 certifi 2026.10.23。
• 旧环境不自动更新：10 月 23 日之前创建的环境会保留旧 certifi，需要手动刷新。

主要功能

• 逐个说明七个参考服务器在证书链上的受影响面
• 明确 TypeScript 服务器自身不携带 CA 证书，由 Node.js 负责校验
• 说明 server-filesystem、server-memory、server-sequential-thinking 等不做网络连接
• 把 fetch 的 Dockerfile 锁文件升级到 certifi 2026.10.23
• 同步发布四个 npm 包与三个 PyPI 包的新版本
• 给出运行时与依赖的自查命令清单

技术原理

这条消息的价值在于它把「上游证书事件」翻译成了一份可执行的自查清单，而不是一句笼统的「请升级」。

逻辑是这样的：证书校验依赖信任库，而信任库不是 MCP 自己的。TypeScript 写的参考服务器自己不带任何 CA 证书，它跑在哪个 Node.js 上，就用哪个 Node.js 的内置信任库去校验 HTTPS。所以 eMudhra 那批根证书该不该被移除，取决于 Node.js 的版本——答案在 Node.js 10 月 21 日的安全版本里，不在 MCP 仓库里。Python 侧的 mcp-server-fetch 走的是另一条路：它通过 httpx 依赖 certifi 的信任包，因此答案在 certifi 2026.10.23 里。

问题出在「不自动」这三个字上。官方明确提醒两点：一是包的 engines 字段接受任意 Node.js 24，所以就算你跑在一个打了补丁之前的运行时上，npm 也不会警告；二是 10 月 23 日之前创建的 Python 环境会一直留着旧 certifi，除非你主动刷新。也就是说，这次发布能改的是仓库自己的锁文件，改不了你机器上已经存在的环境。

另外值得注意的是，正文把「谁做网络连接」也分开了：server-everything 会发起出站 HTTPS 请求（gzip-file-as-resource），server-filesystem、server-memory、server-sequential-thinking 与 mcp-server-git、mcp-server-time 都不做网络连接。对不做网络连接的服务器来说，证书信任库的变化影响面本来就小，这份说明避免了无差别升级。

实际体验

建议按下面顺序自查，重点是分清「仓库改了什么」和「你要改什么」。

第一步，先看自己跑的是哪类服务器。如果只用 filesystem、memory、git、time 这几个不做网络连接的，证书链这条线上的直接风险低，可以把注意力放在 Node.js 运行时本身那批无关的高危漏洞修复上。

第二步，如果用 npx 或全局安装跑 TypeScript 服务器，检查 Node.js 版本。官方要求 24.22.1 或 26.12.1 及以上，用 node --version 确认。不要指望 npm 提醒你——engines 字段接受任意 Node.js 24。

第三步，如果用 mcp-server-fetch，刷新依赖而不是只升级包。旧环境要用 uvx --refresh mcp-server-fetch 或 pip install -U certifi，否则锁在旧 certifi 上不会自动跟上。

第四步，检查 Docker 部署。如果用的是仓库里的 fetch Dockerfile，本次发布已把锁文件移到 certifi 2026.10.23；如果是自己维护的镜像，需要确认镜像里的 certifi 版本而不是只更新镜像标签。

项目地址与获取方式

项目开源在 GitHub 的 modelcontextprotocol/servers 仓库，本次发布的正文即为本文事实来源。本次同步发布的包包括 npm 上的 @modelcontextprotocol/server-everything 2.1.0、server-filesystem 2.1.0、server-memory 2.0.1，以及 PyPI 上的 mcp-server-fetch、mcp-server-git、mcp-server-time（均为 2026.10.28）；server-sequential-thinking 本次版本未变。请通过官方 npm 与 PyPI 源获取，并核对包签名与版本，不要使用第三方镜像或未署名分发的构建。

适合谁用

• 在生产里跑 MCP 参考服务器的团队：这次发布给了逐包的对照表，值得照着自查一遍。
• 用 npx 直接拉 TypeScript 服务器的人：需要自己确认 Node.js 运行时版本。
• 用 mcp-server-fetch 做抓取的 Python 项目：certifi 的刷新步骤不能省。
• 自己维护 Docker 镜像的部署方：要检查镜像内的依赖版本，而不是只更新标签。
• 暂时不必紧张：只用不做网络连接的本地服务器、且运行时已经跟上的场景，影响面有限。

常见问题

这次发布修的是 MCP 自己的漏洞吗？

不是。正文把它定位为一次安全对齐发布：上游的 eMudhra 证书事件由 Node.js 与 certifi 各自处理，本次发布说明的是七个参考服务器各自站在哪一边，以及使用者需要自己做什么。

我用的服务器会发起网络请求吗？

按正文说明，只有 server-everything 会发起出站 HTTPS 请求（gzip-file-as-resource）。server-filesystem、server-memory、server-sequential-thinking 与 mcp-server-git、mcp-server-time 都不做网络连接。

为什么没人提醒我升级 Node.js？

官方明确提到，这些包的 engines 字段接受任意 Node.js 24，因此 npm 不会因为你跑在打了补丁之前的运行时上而给出警告。需要自己用 node --version 核对，官方建议 24.22.1 或 26.12.1 及以上。

只升级 mcp-server-fetch 够吗？

不保证够。官方指出 10 月 23 日之前创建的 Python 环境会保留旧 certifi，需要用 uvx --refresh mcp-server-fetch 或 pip install -U certifi 主动刷新。

用 Docker 部署的要做什么？

仓库的 fetch Dockerfile 已在本次发布把锁文件移到 certifi 2026.10.23。如果是自己维护的镜像，需要检查镜像内实际安装的 certifi 版本，而不是只更新镜像标签。

相关工具与内容

• MCP 官方参考服务器 2.1.0：修复 8 个安全漏洞
• MCP 官方参考服务器发布 1.0.0
• FastMCP 一天发两个版本：凭证库要跟着 eMudhra 事件升级
• AI 编程
• AI Agent
• AI 办公助手