60天30个CVE：MCP生产部署的四个控制层

2026年最初的六十天里，针对MCP部署的CVE报告超过了三十个。这个数字来自一支团队在2025年底把MCP（Model Context Protocol，模型上下文协议）作为生产级多智能体平台集成层之后的持续观察。他们当时只问了一个问题：在大规模自动化执行之前，需要哪些架构控制才能让人信任它？

答案不是网关。网关是集中认证、授权、审计与策略评估的地方，但它只是一个强制执行点，不是完整的控制平面。网关无法确保工具处理器安全地执行参数，无法隔离围绕MCP的检查器、测试工具与管理控制台，也无法阻止服务器用过宽的凭据发起不安全的出站调用。

四个控制层，四个强制执行点

把MCP安全拆成四层，每一层都有自己的最早可信任强制执行点，通常也由不同团队负责。这种拆分不是从四个角度看同一个问题，而是四条相互独立的安全边界。

• 第1层是执行，即调用工具时运行的代码。
• 第2层是管理基础设施，包括检查器、harness、注册界面和管理控制台。
• 第3层是出站信任边界，即服务器自行可达的目标。
• 第4层是语义完整性，即工具定义随时间推移，其含义是否还保持一致。

加固执行环境对存在漏洞的出站路径毫无帮助，固定Manifest也无法证明检查器的身份合法性。网关只参与其中两层，而且是部分参与。

第1层：工具处理器是输入边界

在2026年前六十天记录的30个CVE中，有13个呈现出相同的模式：未验证的用户控制输入到达了shell或动态解释器。CVE-2026-2130（mcp-maigret）、CVE-2026-2178（xcode-mcp-server）与CVE-2026-2131（HarmonyOS-mcp-server）均通过exec()执行了工具参数。CVE-2026-1977在Python中对图表规范的参数使用了eval()。CVE-2026-27203通过未经验证的换行符操纵环境变量，导致在下次服务器重启后触发载荷。

命令注入不是新概念。在MCP中它之所以在架构上重要，原因在信任模型：开发者把工具参数视为带类型的JSON，JSON模式说明了输入结构，但它并未就值在shell执行环境下的安全性作出保证。

修复方式是把字符串插值换成基于数组的参数传递。前者会让分号被shell解释，后者把分号和元字符当作字面值传入。架构原则是：工具处理器不是便捷的工具化包装器，而是受控的输入边界。

CI规则比代码审查清单更管用。Semgrep规则可以在构建时阻止把工具处理器参数传入shell解释器的代码提交，覆盖JavaScript、TypeScript与Python。这些规则是起点，生产环境的规则集应该扩展到其他解释器、间接汇流点与特定语言的规避手段。

Huang等人构建了114个恶意MCP服务器的数据集，表明多组件攻击链常常比单组件攻击更有效。这支持分层防御：不应该期望任何单一控制机制捕获所有问题，每个信任边界都需要自己的防护。

第2层：管理平面默认是开放的

在评估MCP时，这支团队发现测试harness监听了一个没有认证的内部网络。关闭它只花了二十分钟，但它默认是开放的。快速部署MCP的团队大多在别人发现之前不会注意到这种暴露。

测试harness属于管理平面：授予信任权限和注册工具的界面。一旦它被攻陷，攻击者获得的远不止一次工具调用的权限。在30个CVE中，有6个针对的是MCP的开发与运行基础设施，而不是协议本身。CVE-2026-23744（MCPJam Inspector）打开了一个未认证的端点，默认监听0.0.0.0，导致可安装任意的MCP服务器；CVE-2026-23523（Dive MCP Host）则利用精心构造的深链接在用户客户端应用内安装恶意配置。

这一层关键，是因为开发环境通常比生产环境提供更多访问权限：源代码、密钥、构建系统与部署凭据。对管理平面的期望应该与对CI/CD控制面的期望一致——禁止匿名访问、默认不对外暴露广泛的内部网络访问、最小化文件系统可达范围、尽可能使用短期凭据、管理端点必须认证并记录日志。检查器、harness和注册界面应当被视为“接近生产”的组件，因为它们确实如此。

第3层：入站认证挡不住出站泄露

Azure MCP Server的SSRF漏洞（CVE-2026-26118，CVSS 8.8）说明了为何仅靠入站认证不够。攻击者将Azure资源标识符替换为恶意URL，服务器使用其托管身份令牌向该URL发起出站调用，从而让攻击者控制服务器可访问的Azure资源。微软在3月10日发布补丁修复了该漏洞。

三项控制需要并行采用：对每个入站端点强制认证；受控的出站访问，使服务器只能访问其运行所需的服务；确保下游凭据权限最小化，使令牌的影响范围与工具的影响范围相匹配。

NetworkPolicy可以限制MCP服务器的出站流量，只放行内部服务与DNS，其余默认拒绝。这里有两个假设值得说明：集群的CNI必须真正执行NetworkPolicy，Calico、Cilium等能够做到，一些默认安装方式可能无法做到；在选定pod下列出Egress作为policyTypes会拒绝所有未明确允许的流量，但与命名空间范围内的默认拒绝策略配对使用会更明确。

自动化的文件搜索工具不应持有可控制公司云账户的访问令牌。如果工具需要访问新的域或内部服务，那应该是一次显式的变更，而非隐式行为。许多基于代理的系统保护了“前门”，却忘记了进入进程后还能做什么。

第4层：语义漂移比语法漏洞更危险

最具架构意义的攻击不是输入验证漏洞，而是语义层面的攻击。请求可能格式正确、模式合法、通过了认证，但仍然具有危险性，因为工具的含义在被授予信任后发生了漂移。

Pillar Security在2026年3月指出了与MCP相关的11类漏洞，包括供应链拼写仿冒与跨服务器上下文滥用。Solo.io提出了“rug-pull”攻击，即服务器在注册后改变工具的定义。Maloyan与Namiot（2026）将该问题正式化为“缺乏能力认证”：协议缺少在执行时证明工具定义未变的能力。

应对方式是在注册时对工具Manifest进行固定，把基于差异的评审作为运维模型，而不是简单的允许/拒绝门控。这样批准后的模式漂移和rug-pull行为会在注册边界上暴露出来。

规范会随后补上，生产不能等

来自Adversa AI的三月份数据表明，在扫描五百多个MCP服务器时，38%的关键端点缺少认证，43%存在命令执行漏洞。3月9日，主维护者David Soria Parra发布了2026 MCP路线图，文档将“企业就绪性”列为优先关注的领域，但同时指出在四个方向中它可能是最不明确的。

在2026年4月2日至3日的MCP开发者峰会上，亚马逊云科技与优步分享了它们的MCP Gateway与Registry的生产架构，Pinterest的工程团队也公布了其域专用的MCP服务器生态。企业级生产环境MCP的使用速度快于安全规范成熟的速度。

这些并非孤立的缺陷，它们在少数的几个边界处聚集，需要架构性的响应而非零星的修补。优先考虑可操作性：CI门控、隔离工具、基于差异的Manifest评审与行为基线。规范会随后补上，但生产不能等待。