MCPhantom：AI 编程智能体会从训练数据里装回存在漏洞的废弃 MCP 服务器

glow.io 2026-11-03T18:38:21.976000+08:00

Nadav Claude Cohen

MCPhantom: AI Coding Agents Are Installing Vulnerable Deprecated MCP Servers From Training Data

Glow Labs 研究团队发现，AI 编程智能体会自行决定安装已经废弃的 MCP（Model Context Protocol，模型上下文协议）服务器。这类服务器早已不再接收安全更新，一旦装到机器上，可能让企业暴露在严重漏洞之下。

Glow Labs 把这种现象叫作 MCPhantom，指的是那些已经退役的 MCP 服务器反复出现在开发者机器上的情况。

研究团队是在监控智能体的高风险行为时发现这一模式的。他们跟踪智能体的活动、识别 MCP 安装动作，并评估其决策过程。

在智能体安装废弃 MCP 服务器的会话中，有 98% 的情况看起来是因为该服务器曾出现在模型的训练数据里，才被选中。

也就是说，当用户提出某种能力需求时，比如“要一个 GitHub MCP”，智能体会凭自己过去“知道”的内容填入服务器名称，而不是去挑官方或最新的那个 MCP。

剩下 2% 的情况是用户直接点名要某个废弃包，智能体照办。

以 GitHub 为例，智能体没有选择 GitHub 官方维护的 MCP 服务器，而是选了它从训练数据里记住的一个 Anthropic 废弃服务器，也没有去查找最新的安全版本。

该服务器所在的仓库已经归档，其归档说明写明：不再提供安全更新或缺陷修复。

对安全团队来说，这意味着重大风险：软件基于 AI 代理的训练数据被装到开发者机器上，而几乎没有任何信号提示它已不再维护。

与此同时，代理不会太在意归档提示，所以即使标记清晰，风险依然存在。

Glow Labs 发现了什么？

Glow Labs 审查了真实的 AI 编程会话记录，发现有些会话中代理安装了已弃用的本地 Anthropic MCP 服务器，并在端点（endpoint）上运行。

由于这些 MCP 服务器在本地运行，之前在其他扫描中从未出现，只有在端点资产的盘点过程中才被发现。

以下是一个开发者请求如何变成弃用安装的过程：

开发者让代理连接某个服务，比如 GitHub。
代理从训练数据中填入一个早期参考服务器的名称。
代理要么自己写出 MCP 配置，要么把命令交给开发者，然后 npm 安装了这个已弃用的包。

相同模式在数据中的每个工具和每个模型提供商上都出现了，因此没有任何单一厂商的修复能堵住这个缺口：

代理框架：Claude Code、Cursor、Codex CLI、Claude Cowork 和 Claude 聊天
模型提供商：Anthropic、OpenAI 和 xAI

随后团队查看了代理实际安装了什么，发现的问题更严重：

在 Anthropic 推出 MCP 时创建的原始弃用服务器中，发现了四个高危漏洞，包括 Puppeteer 服务器中的远程代码执行漏洞
这些服务器使用非常广泛，自 2025 年 7 月以来，Anthropic 的弃用参考服务器在 npm 上的下载量达 1700 万次，其中五个进入了 npm 的 MCP 前 100 名
不会有修复，因为至少在一个案例中，维护者已确认他们不会继续参与

智能体为什么总挑已经废弃的服务器？

这些场景里都没有恶意攻击者。风险来自智能体自己选的软件包——它依据的是训练时学到的东西。

生态飞速生长，旧服务器被甩在身后

AI 工具生态长得很快，快增长的代价就是大量新旧更替。

研究者 Haseeb Mohammed Afsar 对官方 MCP 注册表做过一次独立统计，发现每天新增约 195 个服务器；GitHub 的 Octoverse 2025 报告则统计出 430 万个与 AI 相关的仓库。

MCP 自己的历史就是个好例子。Anthropic 在 2024 年推出 MCP 时，发布了 20 个参考服务器，向开发者演示如何构建集成。

后来大多数服务都自建了服务器，这 20 个参考服务器里有 13 个被归档——这在生态走向成熟的过程中很正常。

GitHub 和其他服务上线了自己的服务器之后，Anthropic 没什么理由再维护重复的东西。

这也意味着没人负责修它们——Puppeteer 服务器维护者的回复就说明了这点。

这些智能体靠训练数据干活，找最新软件包不在它的任务清单上

模型学到的是：想给 GitHub 弄一个 MCP 服务器时该用哪个包名。至于这个名字后来有没有被废弃，不在它的训练内容里。

npm 上的「已废弃」标记也堵不上这个缺口。废弃的包会从 npm 搜索结果里消失——这大概能解释为什么大部分网页搜索都查不到；但用 npx 照样能装，只弹一个警告。

现有管控机制为什么拦不住废弃的 MCP 服务器

说白了，这些 MCP 服务器是「从不写进依赖文件」的依赖，专门盯着依赖文件的安全工具根本看不到它们。

防护手段	监控内容	为什么没拦住
EDR（终端检测与响应）	恶意文件和异常行为	安装动作来自一个可信的 Node 进程，装的是智能体主动请求的公开 npm 包，看起来完全正常。
SCA（软件成分分析）	依赖清单中的已知漏洞组件	用 npx 启动的服务器不会出现在任何项目的依赖清单里，而且这些漏洞本身也没有对应的 CVE 编号。
智能体运行框架的防护规则	智能体允许执行哪些操作	框架并不知道这个包已经被废弃，自然无从拦截。
软件资产清单	已安装的应用程序	npx 启动的服务器跑在 Node 进程内部，不会以“已安装应用”的形式出现。

于是，唯一能暴露这个问题的地方，就是终端本身——也就是智能体写入配置、执行安装的那台机器。

包名	2025 年 7 月 10 日以来的下载量
server-github	5,266,085
server-postgres	4,312,874
server-slack	3,198,630
server-puppeteer	1,487,526
server-brave-search	1,461,811
server-google-maps	814,615
server-gitlab	273,296
server-gdrive	247,891
server-redis	131,160
create-server	122,534
server-aws-kb-retrieval	23,028
server-everart	12,817
合计	17,352,267

攻击者能利用这些服务器做什么？

四个漏洞中最严重的一个，是 Puppeteer 服务器中的远程代码执行（RCE）漏洞。这个服务器的作用是让 AI 智能体打开浏览器会话。

能做什么：攻击者通过提示注入，可以让智能体不去启动浏览器，而是在机器上启动任意进程、执行任意命令。
为什么防护没起作用：开发者本来就授权智能体浏览网页，而这个权限实际上覆盖了任意命令的执行，所以智能体运行框架不会拦截。

该漏洞由 Glow Labs 报告。维护者回复说，这个服务器已于 2025 年 5 月归档，“已无人维护，本仓库不会提供修复或新版本”。他们将报告标记为超出范围并关闭，同时表示会考虑把该 npm 包标记为废弃，以便提醒用户。

截至目前，Glow Labs 还没有发现有人利用这些漏洞。但官方不会发布补丁，这扇门就一直敞着。再加上 AI 驱动的漏洞挖掘带来的担忧，这些漏洞被发现的可能性已经大幅上升。

安全团队现在该做什么？

安全团队用现有工具就能采取以下措施：

找出并替换已弃用的服务器。在开发者机器上搜索引用了已弃用的 @modelcontextprotocolservers 的 MCP 配置，如果服务提供方有自己的 MCP 服务器，就切换过去。
每个服务只批准一个 MCP 服务器。为每项服务选定一个方案，并把它定为整个环境的标准用法，防止智能体退回到训练数据里的过时模型。
批准前先查弃用状态。把 npm 的弃用状态纳入 MCP 服务器的审批标准。

Glow 客户该做什么？

Glow 客户只需一个请求，就能找出开发者机器上所有已弃用的 MCP 服务器。Glowy 是 Glow 的 AI 平台智能体，它基于每台受管开发者机器上的智能体插件和 MCP 服务器清单工作，覆盖 20 多种 AI 工具。

安全工程师可以这样用：

查看问题列表。Glow 的发现能力和 Glow Labs 的研究已经标记出端点上的所有含已知漏洞的已弃用 MCP 服务器，所以端点上的 MCPhantom 已经出现在你的问题列表里。
直接问。比如问“哪些端点配置了已弃用的 @modelcontextprotocol 服务器？”Glowy 会返回端点、服务器及其版本。
移除。工程师批准后，Glowy 会删除每个端点上该 MCP 服务器的配置项。
让整个机群保持干净。设置一条基于 npm 弃用状态的策略，Glow 会在下次扫描时标记每个端点上的所有已弃用服务器，包括新安装的。
拦截并引导智能体。当智能体尝试使用已弃用的服务器时，Glow 会拦截该调用，并引导智能体改用已批准的服务器。
把替换方案告知开发者。Glowy 可以通过邮件、Slack 消息通知受影响的开发者，也可以创建 Jira 或 ServiceNow 工单。