MCP 生产环境安全需超越网关，构建执行、基础设施、出站信任与语义完整性四层纵深防御

一句话结论

MCP 生产环境安全需超越单一网关，通过执行、基础设施、出站信任与语义完整性四层控制构建纵深防御以应对 2026 年激增的漏洞风险。

关键要点

• 2026 年首 60 天针对 MCP 的 CVE 超过 30 个，Adversa AI 数据显示 500 多个 MCP 服务器中 38% 关键端点缺失认证，43% 存在命令执行漏洞。
• 微软于 2026 年 3 月 10 日修复 Azure MCP Server SSRF 漏洞（CVE-2026-26118，CVSS 8.8），该漏洞导致托管身份令牌泄露。
• 推荐实施四层控制：第 1 层安全工具执行、第 2 层隔离管理平面、第 3 层受限出站信任、第 4 层通过 Manifest 固定实现的语义完整性。
• 短期运行器隔离使工具调用延迟增加 50 至 200 毫秒，大多数 MCP 服务器连接 3 至 5 个内部服务及 1 至 2 个外部 API。
• MCP 规范及 2026 路线图未涵盖 Manifest 固定机制，需网关层自行实现，更新时实质性修改需进入人工评审队列。

背景与事实

模型上下文协议（Model Context Protocol，MCP）在快速普及的过程中暴露出严峻的安全短板。Adversa AI 在 2026 年 3 月的数据显示，在 500 多个 MCP 服务器样本中，38% 的关键端点缺失认证机制，43% 存在命令执行漏洞。2026 年首 60 天内，针对 MCP 的通用漏洞披露编号（CVE）超过 30 个。其中，13 个 CVE 涉及未验证用户输入直接到达 shell 或动态解释器，具体案例包括使用 exec() 的 CVE-2026-2130、CVE-2026-2178、CVE-2026-2131，使用 eval() 的 CVE-2026-1977，以及通过环境变量操纵的 CVE-2026-27203。此外，6 个 CVE 直接针对基础设施层，如 CVE-2026-23744 中 MCPJam Inspector 未认证端点监听 0.0.0.0 地址，以及 CVE-2026-23523 中 Dive MCP Host 面临的深链接攻击。

微软在 2026 年 3 月 10 日修复了 Azure MCP Server 的服务端请求伪造（SSRF）漏洞（CVE-2026-26118），其 CVSS 评分高达 8.8，该漏洞直接导致托管身份令牌泄露。同期，MCP 主维护者 David Soria Parra 于 3 月 9 日发布 2026 年路线图，将“企业就绪性”列为优先但定义最模糊的领域。在 4 月 2 日至 3 日的 MCP 开发者峰会上，亚马逊云科技和优步（Uber）分享了网关与注册表架构实践，Pinterest 则公布了域专用 MCP 服务器生态。Huang 等人构建的 114 个恶意 MCP 服务器数据集表明，多组件攻击链比单一漏洞更具破坏力。

在技术实现层面，Kubernetes 网络策略（NetworkPolicy）成为限制 mcp-server Pod 出站流量的核心手段，配置仅允许访问 10.0.0.0/8 网段的 443 端口及 DNS 53 端口（UDP），并拒绝其他出站流量。该策略依赖 Calico 或 Cilium 等 CNI 插件执行，建议配合命名空间默认拒绝策略使用。Pillar Security 在 2026 年 3 月指出 MCP 相关 11 类漏洞，包括供应链拼写仿冒与跨服务器上下文滥用；Solo.io 提出“rug-pull”攻击概念，指服务器注册后篡改工具定义；Maloyan 与 Namiot 将此问题定义为“缺乏能力认证”。针对语义完整性，Manifest 固定机制在网关层实现，注册时对工具名称、描述及参数模式进行 SHA-256 哈希并存储，建议采用 RFC 8785 规范 JSON 编码以确保哈希一致性。

影响分析

对于中文开发者与企业从业者而言，这一系列发现意味着不能仅依赖网络边界防护，而必须将安全左移至应用层与基础设施层。实施四层控制模型（安全工具执行、隔离管理平面、受限出站信任、语义完整性）需要重构现有的 CI/CD 流程。具体而言，自动化推广计划为期四周：第 1 周隔离管理控制台并限制文件系统访问；第 2 周在 CI 中标记 shell 插值与 eval 调用；第 3 周实施出站允许列表并替换宽泛凭据；第 4 周启用 Manifest 固定评审并收集行为基线。行为基线需 2 至 3 周稳定，低流量服务器周期更长。虽然短期运行器隔离会增加 50 至 200 毫秒的工具调用延迟，但鉴于大多数 MCP 服务器仅连接 3 至 5 个内部服务及 1 至 2 个外部 API，这一性能代价在保护敏感数据免受 SSRF 和令牌泄露风险下是合理的。开发者需特别注意，当前 MCP 规范未涵盖 Manifest 固定，需自行在网关层开发实现，且自动化工具不应持有控制云账户的访问令牌，访问新域需显式变更。

适用边界

上述结论主要适用于采用容器化部署（如 Kubernetes）且具备 DevSecOps 能力的中大型企业生产环境。对于资源有限、缺乏 CNI 插件（如 Calico/Cilium）支持或无法承受 50-200ms 额外延迟的高频实时交易场景，全面实施四层纵深防御可能存在可行性障碍。此外，由于 Manifest 固定机制需网关层自行实现且规范未覆盖，依赖标准开源网关且无法修改代码的团队可能难以快速落地第 4 层控制。在身份认证领域，由于 NIST 和 OASIS 尚未就服务器是携带自身凭据还是代表人类用户承载委托权限达成行业共识，相关授权策略的落地仍需谨慎评估法律与合规风险。

孤本观察

MCP 安全正从单纯的流量过滤转向语义完整性保护，Manifest 固定机制虽未在规范中定义，但已成为填补“rug-pull”攻击漏洞的关键实践。

来源：InfoQ 中文 AI