返回资料库
安全与治理

MCP 安全加固清单：1,467 台暴露服务器以及关闭它们的方法

作者：最后更新：2026年7月26日

Trend Micro 扫描了互联网，发现 1,467 个 MCP 服务器裸露在外——没有认证、没有加密、任何人都能访问。Practical DevSecOps 发现 2,614 个受调查服务器中有 82% 存在路径遍历漏洞。一个为将 AI 代理接入企业系统而设计的协议在发布时没有生产安全基线，部署模式也证明了这一点：大多数团队在加固 MCP 之前就把它暴露到了互联网。这份清单是本应最先到来的基线——涵盖传输、认证、工具注册、运行时和审计的 12 项控制，每一项都能在五分钟内验证完毕，确保 MCP 服务器在承接生产流量之前达标。

关键要点

  • 1,467 台 MCP 服务器公开可访问且零认证零加密 — Trend Micro 修正后的扫描，2026 年 7 月。其中 1,227 台运行 2026-07-28 规范以 12 个月弃用时钟淘汰的 SSE 传输。
  • 2,614 台受调查 MCP 服务器中 82% 易受路径遍历攻击，仅 8.5% 使用 OAuth — Practical DevSecOps MCP Security Statistics 2026 Report。这些攻击类别在已部署服务器中广泛存在，不是理论性的。
  • 2026 年 7 月官方 MCP Python SDK 中出现 3 个 CVE — CVE-2026-59950（DNS rebinding/CSRF）、CVE-2026-52869（未验证的会话请求）、CVE-2026-52870（开放任务处理器）。参考实现与它支撑的社区服务器存在同类缺陷。
  • 5 台 MCP 服务器连接 1 个 agent 时攻击成功率达 78.3% — Palo Alto Networks Unit 42。五台服务器是典型部署，不是大规模部署。OX Security 识别出一个影响 150M+ 下载量的架构级 RCE，Cloud Security Alliance 将 MCP 安全归类为系统性设计缺陷问题。
  • MCP 2026-07-28 规范于 2026 年 7 月 28 日正式发布 — 四个 Tier 1 SDK（TypeScript、Python、Go、C#）在发布日均支持新的无状态核心，SSE 传输有 12 个月弃用策略。迁移和加固是同一项工作。

通过这份清单 12 项控制的生产 MCP 部署不是不可入侵的——没有任何系统是——但它不再属于 Trend Micro 发现的、Practical DevSecOps 扫描的、或 7 月 CVE 波捕获的那批服务器。清单将每项控制映射到它所解决的 OWASP MCP Top 10 类别、它所预防的 CVE 或暴露、以及操作员可在五分钟内运行的验证步骤。Microsoft Agent Governance Toolkit——首个具备 10/10 OWASP MCP Top 10 覆盖的超大规模厂商开源治理运行时——是参考实现。本文是运营层面的补充：一份可扫描的加固审查，面向准备将 MCP 服务器暴露于生产流量的工程负责人或平台负责人。

攻击面，用数字说话

OWASP MCP Top 10（Beta Release v0.1，Phase 3 of 5）编目了 MCP 启用系统全生命周期的 10 个命名风险类别。背后的数字将"治理是好实践"变成"治理是生产门控"：

  • 1,467 台暴露服务器 — Trend Micro 修正后的扫描 发现 1,467 台公开可访问的 MCP 服务器，无认证无加密，从初始计数 492 上升。1,227 台运行弃用的 SSE 传输。至少三台通过 progress_note 工具暴露患者医疗记录。execute_sql 工具出现在 70 台主机上。
  • 82% 路径遍历暴露 — Practical DevSecOps 在 2,614 台受调查服务器中测得 82% 路径遍历漏洞和 8.5% OAuth 采用率。97M+ 月度 MCP 下载量意味着暴露随采用规模增长。
  • 150M+ 下载量受架构级 RCE 影响 — OX Security 将 STDIO 命令注入根因定性为架构级缺陷，而非孤立的 CVE。Cloud Security Alliance 将其归类为 AI agent 基础设施中的系统性设计缺陷问题。
  • 2026 年 7 月 SDK 中 3 个 CVE — CVE-2026-59950（缺少 Host/Origin 验证、DNS rebinding/CSRF）、CVE-2026-52869（未验证的会话请求）、CVE-2026-52870（开放任务处理器）。官方 Python SDK——每个 Python MCP 服务器继承的参考实现——与它支撑的社区服务器存在同类缺陷。
  • 最终规范中的 3 个新攻击面 — backslash.security 识别出 2026-07-28 规范中无状态重设计引入的三个新攻击面。新能力创造新入口点，安全社区仍在绘制中。

cataam.com 分析 精准概括了 MCP 安全现状："MCP 安全大致处于十五年前 Web 安全的位置——攻击手法是旧的，只是目标是新的。"下面的加固清单是将 Web 安全从 82% 路径遍历暴露提升到生产系统预期通过的基线的控制集合。同样的控制在此适用。

12 项加固控制

清单围绕五个层级组织，映射到 OWASP MCP Top 10 和 MCP 2026-07-28 规范变更：

MCP Security Hardening Checklist 12 controls across 5 layers — maps to OWASP MCP Top 10 1 Transport & Network Spec 2026-07-28 + OWASP MCP07 2 controls CONTROL 1 SSE to Streamable HTTP migration 12-month deprecation — 1,227 servers affected CONTROL 2 Network isolation & origin validation CVE-2026-59950 — DNS rebinding defense 2 Authentication & Identity OAuth 2.1 + OIDC — spec mandate 2 controls CONTROL 3 OAuth 2.1 + OIDC enforcement RFC 8707 + RFC 9207 — 8.5% baseline CONTROL 4 Agent identity separation NIST OAuth 2.0 + SPIFFE/SPIRE 3 Tool Registration & Supply Chain OWASP MCP03 + MCP04 3 controls CONTROL 5 Tool poisoning scan MCP03 — injection + typosquatting CONTROL 6 Signed provenance MCP04 — AIBOM inventory CONTROL 7 STDIO hardening 150M+ downloads — OX Security 4 Runtime & Execution OWASP MCP05 + MCP06 + MCP10 3 controls CONTROL 8 Rate limiting Per-agent, per-tool, per-window CONTROL 9 Context boundary MCP10 — scoped per tool, no oversharing CONTROL 10 Kill-switch per module Feature-flag disable, no redeploy 5 Audit & Telemetry OWASP MCP08 + MCP09 2 controls CONTROL 11 Per-call audit logging MCP08 — immutable, structured JSON CONTROL 12 Shadow server detection MCP09 — registry vetting, drift monitoring OWASP MCP TOP 10 MAPPED OWASP MCP01-10 Spec 2026-07-28 Microsoft AGT NIST AI Agent CSA 1,467 exposed servers, zero auth 82% path traversal exposure 78.3% attack rate at 5 servers 8.5% use OAuth today 12 controls across 5 layers — ideabosque.com/library

层级 1 — 传输与网络

控制 1：SSE 到 Streamable HTTP 迁移。 MCP 2026-07-28 规范于 2026 年 7 月 28 日正式发布，对 HTTP+SSE 传输实施 12 个月弃用策略。四个 Tier 1 SDK（TypeScript、Python、Go、C#）在发布日均支持新的无状态核心，并附带破坏性变更迁移说明。Trend Micro 扫描中的 1,227 台弃用 SSE 服务器是受影响最大的群体——它们运行的是规范正在淘汰的传输。**验证：**检查服务器的传输配置。如果它提供 SSE，则已进入弃用倒计时。在 12 个月窗口关闭前迁移至 Streamable HTTP。

控制 2：网络隔离与源验证。 CVE-2026-59950——已在 National Vulnerability Database 中确认——是官方 MCP Python SDK 中缺少 Host/Origin 验证的缺陷。受害者访问的网页可通过 DNS rebinding 和 CSRF 驱动其本地 MCP 服务器。浏览器成为攻击者进入操作员认为私有的环回服务器的代理。**验证：**确认服务器在每个请求上验证 Host 和 Origin 头。如果服务器面向互联网，确认它位于阻止来自不可信源直接访问的网络边界之后。一个本不应从公共互联网可达的服务器绝不能从公共互联网访问。

层级 2 — 认证与身份

控制 3：OAuth 2.1 + OIDC 强制执行。 2026-07-28 规范将 OAuth 2.1 加 OpenID Connect 设为强制——从先前的"自带令牌"方式转变。WorkOS 认证迁移指南详述了要求：RFC 8707（Resource Indicators）防止令牌跨服务器重放，Client ID Metadata Documents 取代 Dynamic Client Registration，issuer 验证（RFC 9207）。Practical DevSecOps 的发现——仅 8.5% 的受调查服务器使用 OAuth——是这项控制要提升的基线。**验证：**检查服务器的认证配置。如果它接受未认证请求或使用无 OAuth 的静态 API key，则不合格。确认服务器实现 RFC 8707 resource indicators。

控制 4：Agent 身份分离。 NIST AI Agent Standards Initiative（2026 年 2 月）提议将 agent 视为具有自身生命周期的独立非人类身份：配置、证明、撤销。大多数部署认证人类用户并将该身份传递给 agent。当 agent 采取行动时，审计日志记录的是人类做的。**验证：**确认每个 agent 拥有独立于人类操作员的凭证（OAuth token、SPIFFE SVID）。撤销 agent 身份应停止所有 agent 调用，而不影响人类的访问。

层级 3 — 工具注册与供应链

控制 5：工具投毒扫描。 OWASP MCP03 将工具投毒列为 top-10 风险：rug pulls（受信任工具安装后更新为恶意版本）、schema poisoning（接口定义本身被破坏以误导模型）、tool shadowing（假工具拦截发给真工具的调用）。Microsoft Agent Governance Toolkit 的 McpSecurityScanner 检测工具投毒、typosquatting 和隐藏指令——一个名为 read_flie（typosquatting read_file）的演示工具在描述中注入内容后评分 85/100 风险。**验证：**检查工具注册流程。如果工具在无安全扫描的情况下注册，则不合格。扫描必须覆盖描述中的 prompt injection 模式、针对已知工具名的 typosquatting，以及隐藏的系统指令。

控制 6：签名溯源与依赖监控。 OWASP MCP04 覆盖供应链攻击和依赖篡改。Postmark MCP 后门——野外捕获的第一个恶意 MCP 服务器——是一个看似合法的 npm 包，静默拦截并外泄邮件。它通过了注册审查。UpGuard 的研究发现每 15 个 MCP 服务器中就有一个是旨在冒充合法服务的 lookalike。**验证：**确认部署中的每个 MCP 服务器都有签名溯源记录和 AIBOM（AI Bill of Materials）清单。确认依赖监控处于活动状态并在依赖树中出现新 CVE 时告警。

控制 7：STDIO 加固。 OX Security 的披露识别出 STDIO 配置中影响 150M+ 下载量的架构级 RCE。根因：TypeScript SDK 中的 shell: true 通过配置字符串启用了命令注入。Cloud Security Alliance 将此归类为系统性设计缺陷问题。**验证：**如果服务器使用 STDIO 传输，确认设置了 shell: false 或等效加固。确认命令 allowlist 检查参数，而非仅检查二进制名——Upsonic 和 Flowise 的绕过（CVE-2026-30625、CVE-2026-40933）表明 npx -c <恶意命令> 能通过仅检查二进制的 allowlist。

层级 4 — 运行时与执行

控制 8：速率限制。 每个工具在注册调用中声明自己的速率限制。骨干网按 agent、按工具、按窗口执行限制。当达到限制时，agent 收到带 Retry-After 头的 429 响应。被入侵的 agent 无法耗尽上游 API 配额，因为速率限制在模块边界执行。**验证：**确认每个注册工具都有速率限制。确认限制在模块边界执行，而非在上游 API 执行。没有速率限制的工具是被入侵 agent 可无限制调用的工具。

控制 9：上下文边界。 OWASP MCP10 将上下文注入和过度共享列为 top-10 风险。具有广泛上下文访问权的 agent 会跨租户、会话或用户泄漏信息——对于同一 agent 服务于具有不同数据访问权限的多个客户的 B2B 部署，这一担忧尤为突出。**验证：**确认每个工具仅接收其特定操作所需的上下文。确认上下文窗口按工具划分，而非在所有工具间全局共享。一个在只需单个字段时接收完整会话上下文的工具是数据泄漏面。

控制 10：按模块 kill-switch。 每个 MCP 模块必须能独立禁用，而无需触碰编排骨干。kill switch 是配置变更，不是代码部署。当漏洞披露时——如 7 月 CVE 波在两周内披露了 3 个 SDK CVE 和 7+ 服务器 CVE——操作员的首要问题是：我能否在不中断 agent 的情况下禁用此模块？在受治理的部署中，答案是肯定的。**验证：**确认每个模块可通过 feature flag 或配置变更禁用。确认禁用路径已经过测试——不只是配置过。一个从未被触发过的 kill switch 在需要时将会失效。

层级 5 — 审计与遥测

控制 11：每次调用审计日志。 OWASP MCP08 将缺乏审计和遥测列为 top-10 风险。没有工具调用和上下文变更的日志，令牌窃取和注入仍然不可见。每次工具调用必须记录时间戳、agent ID、工具名、输入哈希（非原始输入——PII 边界）、输出状态、持续时间和上游系统。日志是发送至可观测性管道的结构化 JSON。**验证：**确认每次工具调用产生结构化日志条目。确认日志包含输入哈希而非原始输入。确认日志不可变——入侵服务器的攻击者无法重写审计轨迹。

控制 12：影子服务器检测。 OWASP MCP09 覆盖影子 MCP 服务器——对治理不可见的未批准或未监督部署。UpGuard 发现每 15 个 MCP 服务器中就有一个是 lookalike。安装了错误的 mcp-server-postgress（注意拼写错误）的工程师获得了一个静默外泄 SSH 密钥和 .env 文件的包。**验证：**确认有部署中每个 MCP 服务器的清单。确认清单与已知良好包注册表核对。确认 drift 监控在出现不在清单中的新服务器时告警。

框架如何映射到清单

控制 OWASP MCP Spec 2026-07-28 Microsoft AGT NIST CSA
1. SSE 迁移 — 12 个月弃用 — — —
2. 网络隔离 MCP07 源验证 — — —
3. OAuth 2.1 + OIDC MCP07 强制认证 — OAuth 2.0 —
4. Agent 身份 MCP07 — AgentMesh Identity SPIFFE/SPIRE —
5. 工具投毒扫描 MCP03 — MCP Security Gateway — —
6. 签名溯源 MCP04 — — — —
7. STDIO 加固 MCP05 — — — 系统性设计缺陷
8. 速率限制 — — Policy Engine — —
9. 上下文边界 MCP10 — Response sanitizer — —
10. 按模块 kill-switch — — Hypervisor kill switch — —
11. 每次调用审计日志 MCP08 — Audit + metrics — —
12. 影子服务器检测 MCP09 — — — —

没有任何单一框架覆盖全部 12 项控制。清单是 OWASP、规范、Microsoft、NIST 和 CSA 的交集——每个框架贡献其他框架缺失的控制。Microsoft Agent Governance Toolkit 覆盖 10/10 OWASP MCP Top 10 类别（7/10 完整，3/10 部分并有路线图），是首个具备显式 OWASP 映射的超大规模厂商开源运行时——Agent OS Policy Engine 中 68 项测试，MCP Security Gateway 中 127 项测试，Agent Hypervisor Execution Control 中 80 项测试包括 kill switch。

评分清单

生产就绪的 MCP 服务器通过全部 12 项控制。部分就绪的服务器通过 8–11 项。通过少于 8 项的服务器不应在无文档化补救计划和每项失败控制的目标日期下暴露于生产流量。

得分 状态 行动
12/12 生产就绪 带监控部署
8–11/12 部分就绪 带文档化例外和补救时间线部署
<8/12 未就绪 不部署。先补救失败的控制

最常见的失败模式是通过控制 1–4（传输、认证、身份）而未通过控制 5–12（供应链、运行时、审计）。前四项是架构性的，在设计审查中受到关注。后八项是运营性的，在事件或审计暴露前常被忽视。2026 年 7 月的 CVE 波——两周内 3 个 SDK CVE 和 7+ 服务器 CVE——就是运营控制缺失时的后果。

相关阅读

一个代表性构建：一家中型分销商部署一个 MCP 模块，读取 NetSuite 目录、生成报价、保持库存可用性，并将接受的订单写回 ERP。控制 1–4（SSE 迁移、网络隔离、OAuth、agent 身份）是架构。控制 5–8（工具投毒扫描、签名溯源、STDIO 加固、速率限制）是供应链和运行时层。控制 9–12（上下文边界、kill switch、审计日志、影子检测）是决定模块运行一周还是一年的运营层。一周的 Discovery 阶段产出系统清单和工作流图，使每项控制可在模块接触生产流量前验证。

一周 Discovery。你获得系统清单、工作流图和固定范围——无论你是否与我们合作构建。

想为您的系统构建这个吗？

这里的每份文档都来自真实的生产工作。如果您有目标系统和工作流想法，我们可以在一周内确定范围。

申请定制开发

为期一周的发现阶段。您会拿到系统清单、工作流地图和固定范围——无论您最终是否与我们合作开发。