MCP“设计缺陷”致20万台服务器面临风险：研究人员指出
缺陷还是特性？
安全研究人员发现，某机构官方模型上下文协议（MCP）中存在一个设计缺陷——或者取决于谁在讲述，也可视为基于糟糕设计选择的预期行为——该缺陷可能导致多达20万台服务器面临被完全接管的风险。
Ox研究团队表示，他们“多次”要求某机构修补根本问题，但得到的回复始终是该协议运行良好，尽管目前已针对使用MCP的个别开源工具和AI代理发布了10个高危和严重等级的CVE。Ox认为，一个根本性的补丁本可以降低总计超过1.5亿次下载的软件包的风险，并保护数百万下游用户。
研究人员在一篇博客文章中表示，某机构“拒绝修改协议的架构，称该行为是‘预期的’”。该研究始于2025年11月，包含了30多个负责任的披露流程。
安全策略更新未解决根本问题
在向某机构提交初始报告一周后，该AI供应商悄然发布了更新的安全策略——这似乎是面对AI漏洞时的惯常做法。研究团队在随后一篇30页的论文中写道，更新指南指出MCP适配器（特别是STDIO适配器）应谨慎使用。“这一更改并未修复任何问题，”他们补充道。
根本问题：MCP协议设计缺陷
据安全研究人员称，根本问题在于MCP——一个最初由某机构开发的开源协议，大语言模型、AI应用程序和代理使用它来连接外部数据、系统以及彼此。该协议跨编程语言工作，这意味着任何使用某机构官方MCP软件开发工具包（支持Python、TypeScript、Java和Rust等语言）的开发人员都会继承此漏洞。
MCP使用STDIO（标准输入/输出）作为本地传输机制，允许AI应用程序将MCP服务器作为子进程生成。“但在实践中，它实际上允许任何人运行任意操作系统命令：如果命令成功创建了STDIO服务器，它会返回句柄；但当给定不同命令时，它会在命令执行后返回错误，”Ox研究人员写道。
四类漏洞
滥用这一逻辑可能导致四类不同类型的漏洞。
第一类：未认证和已认证命令注入
允许攻击者输入用户控制的命令，这些命令将直接在服务器上运行，无需认证或清理。这可能导致系统完全受损，任何具有公开面向UI的AI框架都容易受到攻击。
受影响的项目包括所有版本的LangFlow（某机构开源的用于构建AI应用程序和代理的低代码框架）。研究人员表示，他们于1月11日向LangFlow披露了该问题，但尚未发布CVE。
该问题还影响GPT Researcher（一个用于深度研究的开源AI代理），虽然目前尚未有补丁，但已分配CVE追踪编号（CVE-2025-65720）。
第二类：带强化绕过的未认证命令注入
允许恶意行为者绕过开发人员实施的保护和用户输入清理，直接在服务器上运行命令。
Upsonic（CVE-2026-30625）和Flowise（GHSA-c9gw-hvqq-f33r）已进行了强化，只允许运行特定命令（如“python”、“npm”和“npx”），以防御命令注入。理论上，这应该使得无法直接通过“命令”参数发送命令。
然而，Ox团队写道：“我们能够通过允许命令的参数间接注入命令来绕过此行为，例如 npx -c <command>。”
第三类：零点击提示注入
影响AI集成开发环境（IDE）和编码助手，如Windsurf、某代码助手、Cursor、某命令行工具和某机构Copilot。
然而，唯一针对此类漏洞发布的CVE是针对Windsurf的（CVE-2026-30615）。它也是唯一的真正零点击漏洞，用户的提示直接影响MCP JSON配置，无需用户交互。
包括某搜索巨头、某软件巨头和某机构在内的所有其他IDE和供应商均表示，这是已知问题，或者不是有效的安全漏洞，因为它需要明确的用户许可才能修改文件。
第四类：通过MCP市场投毒
威胁猎手表示，他们“成功投毒了”11个此类市场中的9个——但使用的是概念验证型MCP，运行生成空文件的命令，而非恶意软件。
“接受我们提交的市场平台包括月访问量达数十万的网站，”该安全机构写道。“任何一个目录中的单个恶意MCP条目都可能在检测到之前被数千名开发人员安装——每次安装都会让攻击者在开发人员的机器上执行任意命令。”
结论：某机构有责任使MCP默认安全
Ox认为，某机构有能力和责任“使MCP默认安全”。
“协议层面的一项架构更改本可以保护每个下游项目、每个开发人员以及今天依赖MCP的每个最终用户，”研究人员写道。“这就是拥有技术栈的意义所在。”FINISHED
