可对核心业务与用户数据构成直接威胁，其中部分已完成修复。
各厂商的回应态度则各有不同。据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的安全性，却不知道自己可能正在继承一个已被明确记录的攻击面。