Anthropic MCP Inspector 存在严重漏洞，攻击者可利用恶意网站在开发者机器上执行代码。AI开发工具引入新的代码执行途径，开发者机器成高价值目标。建议对不受信任代码执行进行硬件级别隔离，并始终如一地对待开发和生产系统。漏洞已在 0.14.1 版本修复。
译自：MCP Vulnerability Exposes the AI Untrusted Code Crisis
作者：Dan Fernandez
Anthropic 广泛使用的 MCP Inspector 工具中存在一个严重漏洞，攻击者只需诱骗开发者访问恶意网站，即可在开发者机器上执行任意代码。由于超过 5,000 个被 fork 的存储库受到影响，且 CVSS 评分高达 9.4，这代表着 AI 开发生态系统中首批重大的安全危机之一。
这也预示着信任方面存在重大差距，需要加强这些差距，以确保新兴的代理 AI互操作性架构能够安全运行，并使 AI 代理市场能够得到广泛采用。
不受信任的代码正在企业中迅速传播
此漏洞只是最新的一个例子，说明如何安全地运行来自这个新兴生态系统的 AI 生成的代码和相邻组件变得至关重要。
大多数组织都有严格的审批流程，然后才允许任意代码在其环境中运行，无论这些代码来自开源项目还是供应商解决方案。然而，随着这波新工具的出现，我们同时允许数千名员工不断使用任意的、不受信任的 AI 生成的代码来更新代码库，或者将这些代码库和应用程序连接到可以更改或修改其行为的机制。
这并不是要阻止 AI 编码代理的使用，也不是要牺牲它们带来的巨大生产力提升。相反，我们应该标准化更好的方法，使我们能够在软件开发管道中运行不受信任的代码。
开发者机器：通往一切的门户
当安全团队考虑保护其基础设施时，他们会关注生产环境、CI/CD 管道和面向客户的系统。但存在一个巨大的盲点：开发者的本地机器。这不仅仅是另一个端点；它还是访问凭据、源代码、内部文档以及通常与生产基础设施的直接连接的宝库。
开发者的机器可以存储生产服务器的 SSH 密钥、数据库连接字符串、API 密钥、专有应用程序的源代码、内部文档、架构图、与内部网络的 VPN 连接以及云平台的缓存凭据。成功入侵开发者的机器不仅仅会影响一个人；它还可以作为灾难性供应链攻击或数据泄露的初始访问向量。
MCP 漏洞：现代攻击向量的案例研究
最近披露的 Anthropic MCP Inspector 中的漏洞（CVE-2025-49596）可以作为案例研究，说明现代攻击向量如何利用我们对开发者工具的信任。以下是攻击的工作方式：
攻击链：
- 目标设置： 开发者使用默认设置运行 MCP Inspector（通过
mcp dev命令自动发生）。 - 利用： 恶意网站使用 JavaScript 向 http://0.0.0.0:6277 发送请求。
- 代码执行： 该请求触发开发者机器上的任意命令。
- 完全入侵： 攻击者获得对开发环境的完全访问权限。
此漏洞允许仅通过诱骗开发者访问恶意网站来远程执行代码。是什么让这特别危险：
- 除了访问网页之外，无需用户交互
- 通过定位 localhost 服务来绕过传统的安全控制
- 利用仍然未修补的 19 年前的浏览器漏洞（0.0.0.0-day）
- 针对开发者每天使用的合法工具
随着 AI 开发工具在企业中得到采用，出现了一类新的系统来支持它们，这些系统可以代表开发者执行代码。这包括生成和运行代码片段的 AI 代码助手、为 AI 系统提供对本地工具和数据访问权限的 MCP 服务器、执行 AI 生成的测试用例的自动化测试工具以及执行复杂多步骤操作的开发代理。每一个都代表了一个潜在的代码执行途径，通常会绕过传统的安全控制。风险不仅仅在于 AI 生成的代码可能会在无意中具有恶意性；还在于这些新系统也为不受信任的代码执行创建了途径。
AI 开发工具还通过创建新的攻击途径来利用已知漏洞，从而放大了现有的安全风险。例如，传统的 Web 应用程序漏洞现在可以通过 AI 生成的代码或自动化开发代理触发，从而扩大了先前包含的威胁的潜在范围。我们已经看到有进攻性的 AI 公司和解决方案出现，试图利用这一点。
更广泛的不受信任的代码问题
此漏洞并非孤立事件；它是对更大问题的早期警告。AI 开发生态系统正在引入可以代表开发者执行代码的新类别系统。这些包括具有潜在恶意安装后脚本的软件包依赖项、可能包含漏洞或后门的第三方库、恶意提交可以隐藏在明处的开源项目、连接到外部服务的开发工具以及从论坛、文档或教程复制的代码示例。每一个都代表了攻击者的潜在入口点，他们明白开发者机器是高价值目标。
默认隔离
答案不是停止使用 AI 生成的代码或避免外部代码，而是为所有不受信任的代码执行（包括开发环境和生产系统）实施适当的隔离。如果您将安全性押注在容器隔离上，那么您就是在押注 Linux 命名空间做一些它从未被设计用来做的事情。真正的隔离需要硬件级别的分离。容器隔离很方便，但不安全。我们越早认识到这一点，就能越早构建真正保护我们工作负载的系统。
虽然我们在这里重点关注开发环境，但相同的原则也适用于生产环境。Apple 的 容器化框架 正在推动开发环境中所需隔离的验证。但是，需要进行更广泛的转变，以始终如一地对待开发和生产系统，并期望运行时隔离，因为 AI 生成的代码和 AI 开发堆栈中的新组件都可能具有恶意性。同样重要的是使隔离成为默认设置，而不是例外。
MCP 漏洞不仅仅是一个单一的缺陷；它突显了我们的开发环境与可以自主生成、解释和执行代码的 AI 系统之间是如何深入交织在一起的。
随着基于代理的 AI 架构不断发展，它们跨工具、服务和平台进行互操作的能力反映了现代软件供应链中复杂的传递依赖关系网络。正如深度嵌套的库中的弱点会危及整个应用程序一样，具有未经检查的执行权限的 AI 系统会将组织暴露于广泛且可能具有破坏性的风险之中。
目标不是阻止采用 AI 驱动的工具或不信任它们的能力。而是要认识到它们的力量在于连接性和自主性，这也引入了系统性漏洞。随着这个新的 AI 开发生态系统的成熟，我们必须从数十年的软件安全失败中吸取教训，并从头开始构建保护措施。AI 系统中的互操作性必须以与我们应用于软件依赖项相同的安全第一的思维方式来对待，否则我们可能会以更大、更快的规模重复同样的错误。
*本文中讨论的漏洞已在 MCP Inspector 版本 0.14.1 中修复。使用 MCP Inspector 的开发者应确保他们运行的是最新版本，并审查其开发环境安全实践。
