编译 | 陈佳
编辑 | 程茜
智东西4月17日消息， 4月15日以色列网络安全公司OX Security发布研究报告，指出Anthropic主导开发和维护的模型上下文协议（MCP）存在架构级安全漏洞。该漏洞已影响超过3.2万个代码仓库，超20万台服务器存在潜在暴露风险，攻击者可借此直接窃取用户数据、数据库、API密钥及聊天记录。
据OX此次披露的研究报告，其研究团队多次向Anthropic报告该漏洞并建议修复，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余个热门开源项目中数以千计的公开服务器。
OX指出，只要Anthropic在MCP项目层面落地任何一项修复，例如限制STDIO（标准输入输出）接口仅执行预定义命令、在SDK层建立高危命令黑名单，保护就能自动传递至所有下游库和项目，无需对数百个代码仓库逐一打补丁。
然而Anthropic至今未采取任何实质行动，仅在OX向其报告后悄然更新了一份安全策略文档，注明STDIO适配器“应谨慎使用”。
LangChain、微软、谷歌、Cursor、Windsurf等厂商也均以“正常设计”“不符合漏洞标准”“已知问题暂无修复计划”等理由搁置处理。
OX对Anthropic MCP相关漏洞进行负责任披露的全流程时间线，覆盖了从2025年11月至2026年4月的整个漏洞处理周期（图源：OX Security）
一、启动服务入口变后门，漏洞关键在Anthropic的官方代码
OX的调查始于2025年11月，起点是一个名为GPT Researcher的开源项目。该项目在GitHub上拥有超过2.5万颗星，能为大模型提供RAG（检索增强生成）、深度调研和网页浏览等能力。
OX的研究人员注意到，GPT Researcher支持用户自定义STDIO类型的MCP服务器，用户可以自行填写启动命令及参数。STDIO是MCP支持的一种连接方式，开发者在配置文件中填写命令后，MCP会启动对应进程并建立通信。
此次漏洞的核心成因就是，MCP通过STDIO执行配置命令时，不校验该命令是否用于启动服务器，任何系统指令均被直接运行。更危险的是，即便进程启动失败并报错，恶意命令往往也已在后台完成执行。
Anthropic MCP进程执行逻辑的核心漏洞代码片段（图源：OX Security）
顺着依赖链排查，OX最初认为漏洞来自一个流行的AI开发框架LangChain的MCP适配器模块。据OX此次披露的研究报告，OX团队联系LangChain后，对方回应：这属于预期设计范畴，开发者应自行负责输入过滤。
深入溯源后，OX发现根本原因在于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则始终未回应。
四、4项修复自动传递，无需逐一打补丁
OX在报告中指出，这一架构漏洞本可以在MCP设计阶段就彻底避免，只需在协议层采用“安全默认”原则，而非将安全负担转嫁给每一个下游开发者。
OX提出了四项修复建议：
1、在协议层弃用允许用户输入直接流入Shell执行环境的模式，改为仅执行预定义服务器别名的“仅清单”（Manifest-Only）模式。
2、在SDK层实现命令白名单，默认封锁sh、bash、powershell等高风险命令。
3、引入强制标志位，要求开发者显式声明是否启用不安全的本地执行能力。
4、要求MCP集市建立安全清单标准，所有上架MCP包须申报所访问的资源类型并绑定开发者身份验签。
OX强调，上述任何一项修复只要在Anthropic的MCP项目层面实施，保护就会自动传递到所有下游库和项目，无需在数百个代码仓库中逐一打补丁。
结语：AI生态快速扩张，协议层的安全欠账需要被正视
MCP目前已被业界视为AI智能体通信的标准，微软、亚马逊、英伟达等大厂均已在自家AI产品中集成MCP支持。协议的快速普及，使得任何架构层面的缺陷都具有极强的供应链放大效应，一个设计决策，沿着依赖链传递到每一种编程语言、每一个下游库、每一个信任该协议的项目。
更值得关注的是，MCP当前的主要使用群体，恰恰是技术背景较弱的Vibe Coding开发者，即那些借助AI辅助代码生成工具快速上线项目、但缺乏系统安全知识的开发者。他们信任官方SDK的安全性，却不知道自己可能正在继承一个已被明确记录的攻击面。
嘉正网提示：文章来自网络，不代表本站观点。
