Glow Labs：AI编程智能体从训练数据中安装已废弃的漏洞MCP服务器

博客活动与网络研讨会新闻 公司 关于我们招聘信任中心 预约演示 预约演示 预约演示 博客 MCPhantom：AI 编程代理正在从训练数据中安装已弃用的高危 MCP 服务器 Nadav Claude Cohen 2026年11月2日 博客 Glow Labs 发现 AI 编程代理从训练数据中安装已弃用的 MCP 服务器，其中一些存在高危漏洞。了解如何阻止它们。 Nadav Claude Cohen 2026年11月3日 Glow Labs 研究团队发现，AI 编程代理会自行决定安装已弃用的 MCP 服务器，这可能使组织面临高危漏洞的威胁，因为这些服务器已不再接收安全更新。 Glow Labs 将这种现象称为 MCPhantom，即已退役的 MCP 服务器不断出现在开发者机器上。 我们的研究团队是在监控高风险代理行为、跟踪活动、识别 MCP 安装以及评估代理决策过程时发现这一模式的。 在代理搭建已弃用 MCP 服务器的会话中，有 98% 的情况，选择该服务器的原因似乎是它曾出现在模型的训练数据中。 也就是说，当用户请求某项能力（例如“一个 GitHub MCP”）时，代理是根据自己从过去“已知”的内容来填写名称，而不是因为它是官方或最新的 MCP。 在另外 2% 的情况下，用户明确点名要求已弃用的包，代理便照办。 在 GitHub 这个例子中，代理没有选择 GitHub 官方维护的 MCP 服务器，而是选择了它从训练数据中记住的一个已弃用的 Anthropic 服务器，而没有去寻找最新的安全版本。 该服务器的代码仓库已归档，其归档说明写明不再提供安全更新或错误修复。 对安全团队而言，这构成了重大风险，因为软件是基于代理的训练数据落到开发者机器上的，几乎没有任何信号表明它已不再维护。 与此同时，代理不会太在意归档提示，因此即使这些提示标注得很清楚，风险依然存在。 Glow Labs 审查了真实世界的 AI 编程会话记录，发现有些会话中代理搭建了已弃用的本地 Anthropic MCP 服务器，并在终端上运行。 由于这些 MCP 服务器在本地运行，它们此前未出现在其他扫描中，只有在以终端为重点的资产盘点研究中发现本地资产时才被揭露。 以下是一个开发者的请求如何变成一次已弃用安装的过程： 同样的模式在数据中出现的每一个工具和每一家模型提供商身上都得到了体现，因此没有任何单一厂商的修复能弥补这一缺口： 随后团队查看了代理实际安装了什么，而发现的问题在这里变得更加严重： 这些会话都不涉及恶意行为者。相反，风险来自代理自身对包的选择，基于它在训练期间学到的内容。 AI 工具生态系统发展迅速，这种增长意味着大量更替。 研究者 Haseeb Mohammed Afsar 对官方 MCP 注册表进行的一项独立普查统计出每天约有 195 个新服务器，而 GitHub 的 Octoverse 2025 报告统计出 430 万个与 AI 相关的代码仓库。 MCP 自身的历史就是一个很好的例子。当 Anthropic 在 2024 年推出它时，发布了 20 个参考服务器，向开发者展示如何构建集成。 随着大多数服务构建了自己的服务器，其中 13 个参考服务器被归档，这是生态系统走向成熟过程中的正常现象。 一旦 GitHub 和其他服务发布了自己的服务器，Anthropic 就没有什么理由继续维护重复的版本。 这也意味着没有人留下来修复它们，正如维护者在 Puppeteer 服务器上的回复所示。 模型学会了在需要 GitHub 的 MCP 服务器时该使用哪个包名。而这个名称后来是否已被弃用，并不在它的训练内容之中。 npm 上的弃用标记也无法弥补这一缺口。已弃用的包会从 npm 搜索中消失，这或许能解释为什么大多数网络搜索都没有结果，但 npx 仍然会安装它，只不过给出一条警告。 简而言之，这些 MCP 服务器是从不出现在依赖文件中的依赖项，因此那些为监视依赖而构建的工具看不到它们。