Anthropic警示MCP设计缺陷影响超20万台服务器与3万代码库

▲头图由AI辅助生成

智东西
编译 陈佳
编辑 程茜

随着AI生态的迅猛发展，协议层的安全风险正被急剧放大。近日，一份来自安全研究机构的深度报告，曝光了AI领域一项基础协议存在的重大设计缺陷，其潜在影响范围之广，敲响了整个行业的警钟。

4月15日，以色列网络安全公司OX Security发布研究报告，直指由Anthropic主导开发与维护的模型上下文协议（Model Context Protocol， MCP）存在架构级安全漏洞。报告披露，该漏洞可能导致超过3.2万个代码仓库和20万台服务器面临风险，攻击者可借此窃取用户敏感数据、数据库内容、API密钥乃至完整的聊天记录。

尤为令人担忧的是，研究团队在多次向Anthropic报告并建议修复后，得到的官方回应竟是：“这属于预期设计范畴。”

▲OX Security发布的《所有AI供应链之母：Anthropic在AI生态核心处的“设计性”安全失效》报告封面（图源：OX Security）

这一漏洞的严重性在于，它并非偶然的编码错误，而是被系统地内置在Anthropic最新支持的全部10种编程语言的SDK中。这意味着，任何基于Anthropic MCP构建应用的开发者，都在无意中引入了巨大的安全风险。

MCP协议是Anthropic于2024年11月推出的开放标准，旨在为大型语言模型提供统一接口，以调用外部工具、数据库和服务。目前，该协议已被微软、亚马逊、英伟达等科技巨头的AI产品广泛集成。然而，OX的报告指出，该协议的默认通信机制缺乏最基础的输入验证与执行边界隔离，使得“工具调用”与“系统命令执行”之间的安全防线形同虚设。

OX Security的研究团队耗时五个月，完成了超过30次负责任的漏洞披露流程，共发现了10余个严重和高危级别的CVE漏洞。在验证过程中，他们成功在6家拥有真实付费用户的企业生产平台上执行了任意命令，并接管了200多个热门开源项目中数以千计的公开服务器。

报告强调，只要Anthropic在MCP项目层面实施任何一项关键修复，例如限制STDIO接口仅执行预定义命令，或在SDK层建立高危命令黑名单，这种安全防护就能自动覆盖所有下游库和项目，无需对数百个代码仓库逐一打补丁。

但现实情况是，Anthropic至今未采取实质性修复行动。仅在收到OX报告后，悄然更新了一份安全策略文档，在其中注明STDIO适配器“应谨慎使用”。而包括LangChain、微软、谷歌、Cursor、Windsurf在内的其他相关厂商，也纷纷以“正常设计”、“不符合漏洞标准”、“已知问题暂无修复计划”等理由搁置处理。

▲OX对Anthropic MCP相关漏洞进行负责任披露的全流程时间线，覆盖了从2025年11月至2026年4月的整个漏洞处理周期（图源：OX Security）

一、服务入口变后门：漏洞根源于Anthropic最新代码设计

整个调查始于2025年11月，起点是GitHub上一个拥有超过2.5万颗星的开源项目——GPT Researcher。该项目能为大模型提供RAG（检索增强生成）、深度调研和网页浏览等高级能力。

OX的研究人员发现，GPT Researcher支持用户自定义一种名为STDIO类型的MCP服务器。简而言之，用户可以自行填写启动命令及参数。STDIO是MCP支持的一种连接方式，开发者在配置文件中填写命令后，MCP会启动对应的进程并建立通信。

漏洞的核心成因正在于此：MCP通过STDIO执行配置命令时，完全不会校验该命令是否真的用于启动一个合法的服务器。任何系统指令，都会被直接执行。更危险的是，即便进程启动失败并报错，那些嵌入的恶意命令往往也已在后台执行完毕。

▲Anthropic MCP进程执行逻辑的核心漏洞代码片段（图源：OX Security）

通过依赖链向上排查，研究团队最初认为问题出在流行的AI开发框架LangChain的MCP适配器模块上。但联系LangChain后，对方给出了与后来Anthropic几乎一致的回应：这属于预期设计，开发者应自行负责输入过滤。

然而，深入溯源后，真相浮出水面。根本原因在于Anthropic最新的MCP实现代码本身，即MCP项目中的进程启动逻辑存在根本性设计缺陷。

▲Anthropic模型MCP STDIO 接口远程代码执行漏洞原理示意图（图源：OX Security）

这并非某一处的编程疏忽，而是Anthropic在所有最新支持的编程语言SDK中都采用了同样的不安全架构设计，涵盖了Python、TypeScript、Java、Kotlin、C#、Go、Ruby、Swift、PHP和Rust，整整10种语言。任何基于Anthropic MCP最新代码构建项目的开发者，都自动继承了这一安全风险敞口。

▲漏洞存在于所有支持语言（图源：OX Security）

OX向Anthropic报告后，得到了与LangChain一样的答案：“这属于预期设计范畴。”

大约一周后，Anthropic在未通知OX的情况下，更新了其安全策略文档，注明STDIO类型的MCP适配器应谨慎使用。在OX看来，这一变动并未解决任何实质问题，只是更明确地表明，Anthropic选择将安全责任转移给了下游的每一位开发者。

▲所有依赖Anthropic MCP的框架均受影响，包含LangChain MCP适配器、FastMCP、Browser-Use等热门开源项目（图源：OX Security）

二、五条攻击路径曝光，MCP集市安全审查形同虚设

该漏洞的真正危险之处，在于攻击者至少有五条不同的路径可以触发它，令人防不胜防。

最直接的路径，是针对那些将MCP服务器配置界面直接暴露给用户的平台。以AI智能体平台Letta AI为例，其界面原本只提供两种MCP连接类型供用户选择。但OX通过拦截网络请求，将传输类型替换为STDIO并附上恶意命令，最终成功在Letta AI的生产服务器上执行了任意命令。

▲第1类攻击向量漏洞分类统计表（图源：OX Security）

第二条路径，是绕过平台自身设置的防护措施。例如，Flowise平台已经意识到STDIO的风险，并实施了输入过滤，只允许特定命令通过，同时剥离特殊字符。然而，OX仅用了一步就绕过了这层防护——他们利用Node.js包管理器npx的-c参数，将任意命令“藏”在一个被允许的命令之后传入，使得之前的防护措施形同虚设。

第三条路径，则来自AI编程工具中常见的提示词注入（Prompt Injection）攻击。Cursor、VS Code、Windsurf、Claude Code、Gemini-CLI等主流AI编程环境均支持MCP配置，并且都可能被操控。攻击者可以诱导AI智能体修改本地的MCP配置文件，将恶意命令直接写入其中。

▲AI驱动IDE通过提示注入篡改MCP配置实现本地代码执行的攻击链示意图（图源：OX Security）

第四条路径，针对的是那些未做身份验证的公开服务。LangFlow是IBM旗下的一款开源研究自动化框架，其设置界面直接暴露了MCP配置入口，且完全不需要登录。攻击者只需先发送一次网络请求获取会话令牌，再发送一次配置请求注入恶意STDIO命令，即可在未登录的情况下完全接管服务器。OX于2026年1月11日向LangFlow披露此问题，直到3月18日才通过GHSA报告获得直接确认。

▲第2-4类攻击向量漏洞分类统计表（图源：OX Security）

其中，Windsurf的问题最为严重。其MCP配置文件可被AI智能体直接写入，且不向用户展示变更内容，整个攻击链无需任何用户确认。该漏洞已被分配编号CVE-2026-30615。
▲主流AI助手在MCP配置文件编辑环节的安全交互与权限机制评测表（图源：OX Security）

第五条路径，是通过MCP集市（Marketplace）直接分发恶意的MCP包。OX向11个主流MCP集市提交了一个包含任意命令执行能力的概念验证MCP包，结果有9个集市未加任何审查就直接上架，仅GitHub的托管环境因设有安全审核机制而无法提交。

▲第5类攻击向量漏洞分类统计表（图源：OX Security）

这意味着，一个恶意的MCP包可以在被发现之前，被数千名开发者下载安装。而每一次安装，都等同于向攻击者开放了一次命令执行的权限。

▲主流MCP市场恶意插件安全测试结果（图源：OX Security）

三、6个生产平台被攻破，超20万台服务器暴露于风险

OX Security团队披露的数据，量化了这场安全危机的规模。Anthropic最新的MCP Python SDK累计下载量已超过7327万次，FastMCP下载量超过2247万次，LiteLLM下载量超过5725万次。直接或间接依赖这些项目的代码仓库合计达32682个，供应链影响范围巨大。

▲（图源：OX Security）

通过网络空间搜索引擎Shodan进行扫描，OX发现了7374台公开可访问的服务器存在直接漏洞，而潜在暴露的服务器数量估计超过20万台。

为了验证漏洞的实际危害，OX对多家企业级平台开展了测试，成功在包括Letta AI、DocsGPT、OpenHands在内的6个企业生产平台上执行了系统命令。这证明该漏洞足以对核心业务与用户数据构成直接威胁。据悉，其中部分平台在被告知后已完成修复。

面对漏洞报告，各厂商的回应态度则呈现出不同的面貌。根据OX披露的报告，Anthropic和LangChain均以“这属于预期设计范畴”回应；FastMCP称STDIO传输机制按MCP规范设计本就会启动子进程；微软（VS Code）认为其安全要求不符合漏洞标准；谷歌（Gemini-CLI）确认为已知问题，但暂无修复计划；Cursor认为用户需主动点击接受才能触发，属于正常设计；Windsurf则始终未作回应。

四、四项修复建议：从源头阻断风险传递

OX在报告中指出，这一架构漏洞本可以在MCP的设计阶段就彻底避免。关键在于采用“安全默认”的设计原则，而不是将安全负担转嫁给下游的每一个开发者。

为此，OX提出了四项具体的修复建议：

1. 在协议层弃用允许用户输入直接流入Shell执行环境的模式，改为仅执行预定义服务器别名的“仅清单”（Manifest-Only）模式。

2. 在SDK层实现命令白名单机制，默认封锁sh、bash、powershell等高风险的命令解释器。

3. 引入强制性的标志位，要求开发者必须显式声明是否启用不安全的本地执行能力。

4. 要求MCP集市建立安全清单标准，所有上架的MCP包必须申报所访问的资源类型，并进行开发者身份签名验证。

报告强调，上述任何一项修复，只要在Anthropic的MCP项目层面实施，其保护效果就会自动传递到所有下游库和项目中，无需在数百个分散的代码仓库中逐一打补丁。

结语：AI生态狂奔下的安全欠账，协议层风险亟待正视

目前，MCP已被业界广泛视为AI智能体通信的事实标准，微软、亚马逊、英伟达等大厂均已在自家AI产品中集成了MCP支持。协议的快速普及，使得任何架构层面的缺陷都具有极强的供应链放大效应。一个上游的设计决策，会沿着依赖链传递到每一种编程语言、每一个下游库、每一个信任该协议的项目。

更值得关注的是，MCP当前的主要使用群体，恰恰是那些技术背景相对较弱的“氛围编程”（Vibe Coding）开发者。他们借助AI辅助代码生成工具快速上线项目，却可能缺乏系统的安全知识。他们信任最新SDK的安全性，却不知道自己可能正在继承一个已被明确记录的攻击面。

这次事件揭示了一个核心问题：在AI生态狂奔突进的时代，底层协议的安全设计是否跟上了扩张的速度？当“预期设计”成为安全漏洞的托词时，整个生态的信任基础又该如何构建？这无疑是所有AI参与者都需要正视和解决的一笔关键安全欠账。