如果你正在把 AI Agent 接进真实业务——让它读数据库、发邮件、调内部 API——那么有一个名字你绕不开：MCP（Model Context Protocol，模型上下文协议）。它被称作"AI Agent 连接外部世界的通用 USB-C 接口"，2025 年起爆发式普及，如今注册表里的服务器数量已冲到两万以上。但就在最近一个月，五份彼此独立的安全研究像约好了一样，从五个完全不同的角度指向了同一个令人不安的判断：MCP 这个 Agent 与真实世界之间的接口层，安全底座几乎是空的。
一、五份研究，先摆口径再谈结论
安全数据最容易被断章取义吓唬人，所以先把每份研究的来源、样本和方法论边界交代清楚，再引用它的数字。
| 编号 | 来源 | 样本 / 方法 | 核心发现 |
|---|---|---|---|
| R1 | Adversa AI《MCP Security September 2026》(2026-09-07) | 安全公司审计月报，含具体 CVE 与 IoC | 一个月内在其审计的 MCP 服务器中发现 68 个可报告漏洞；追踪名为 Deadbugz 的攻击活动 |
| R2 | arXiv 2608.00150《Exposed by Design》 | 对互联网可访问 MCP 服务器的系统性动态审计 | 91.8% 缺 OAuth；687 个工具实例暴露无访问控制的 shell 执行；高危漏洞占比 15.2%；41.6% 服务器 3 天内消失 |
| R3 | arXiv 2609.14119《Same Name, Different Server》(2026-09-12) | 对 MCP Registry 的全量普查（非抽样），21,643 台服务器、72,606 条版本记录 | 51.1% 多版本服务器在版本间改变对外描述/包/端点，其中 40.6% 标识符未变（即"静默漂移"）；有漂移者高危漏洞概率是无漂移者的 2.96 倍 |
| R4 | OX Security 基础设施分析 (2026-09-24) | 15,465 个 MCP 服务器对应的 5,095 个独立主机名 | 15.6% 解析到美国以外基础设施；2.3% 域名已不再解析（可被抢注冒用）；0.45% 跑在家庭网络/消费者隧道上 |
| R5 | Snyk / Koi Security 披露 postmark-mcp 事件 | 真实在野恶意包，有 npm 记录与下载量 | 攻击者先发 15 个干净版本建立信任，再于 1.0.16 投毒，把每封外发邮件密送给攻击者；被发现前累计下载 1,643 次 |
⚠️ 关键提醒：这几份研究扫描的是整个注册表的"全量"，里面混杂了大量个人玩具项目、demo 和临时测试部署。因此这些比例反映的是"MCP 生态的平均安全水位"，而不是"企业生产环境里精选服务器的水位"——后者大概率好于平均值。此外 R3 的模式扫描器存在假阳性，经 414 个人工标注样本校准后，其高危漏洞率应从观测到的 11.1% 修正为 7.6%（R2 的 15.2% 是另一套定义口径，两者不可直接比较）。把这些边界放在心里，再看下面的结论才不会失真。
二、三个最扎手的数字，各自戳穿一层问题
91.8% 无认证：病根在设计，不在个别开发者
R2 这个数字之所以致命，是因为它意味着绝大多数暴露在公网的 MCP 服务器，任何人都能连接并调用它的工具。其中 687 个实例更是直接把 shell 执行能力敞开——没有访问控制的远程命令执行入口。而 41.6% 的服务器在三天内就消失，暴露出大量"影子 IT"式部署：没有上线评审、没有安全基线、没有日志审计。当一个接口的默认形态就是"不验证你是谁"时，这不是某几个粗心开发者的问题，而是整个协议生态把"便利"排在了"安全"前面。
51.1% 静默漂移：供应链信任模型的结构性裂缝
R3 做了一件前人没做的事——对整个注册表做全量普查而非抽样，然后追踪每台服务器跨版本的变化。结果触目惊心：在有多个版本的服务器中，51.1% 会在版本之间悄悄改掉自己的对外描述、依赖包或远程端点，其中 40.6% 连标识符都不变——你以为连的还是那个可信服务，实际上它早已面目全非。更硬核的关联是：发生漂移的服务器，出现高危漏洞的概率是没漂移者的 2.96 倍（OR=2.96，95% CI [2.56, 3.42]）。而 GitHub 星数对安全性的预测力极弱（OR=0.78/log stars），等于敲碎了"star 多就是安全"这个常见错觉。问题的根源在于 MCP 的信任模型是"按名字连接"，注册表并不保证服务端的一致性——同名服务器今天跑在 A 主机、明天搬到 B 主机，你的 Agent 不会收到任何通知。
postmark-mcp：攻击者已经从理论走进了实战
前面讲的都是"漏洞"和"配置缺陷"，R5 则是最直白的一种——已经有人在真实环境里部署恶意 MCP 服务器了。手法是老练的供应链投毒：先在 npm 发布 postmark-mcp 包伪装成正统邮件服务的集成，连发 15 个干净版本让用户和扫描器都判定它"安全"，然后在 1.0.16 这一个版本里下毒——把用户每一封外发邮件都密送（BCC）到攻击者控制的地址。被发现并从 npm 下架前，它以每周约 1,500 次的速度累计被下载了 1,643 次。这个攻击技术含量并不高，但它暴露了一个结构性事实：MCP 服务器被 Agent 调用时，天然持有用户的凭证、网络位置和文件系统权限，恶意服务器根本不需要提权或绕过任何机制，只需滥用它"已经被授予"的权限就够了。
三、为什么会系统性出问题：三层根因
五份研究角度各异，却共同指向三条根因。第一条是设计哲学：MCP 的目标是"让 Agent 方便地连工具"，而在这个目标里，安全是被后置的项——注册表不做代码审查、不做签名验证、不做来源证明（比早期 npm 还松）；客户端默认连"最新版"而非固定版本；权限模型粗粒度，一旦接入就获得运行环境的全部权限，没有最小权限的默认实现。
第二条是生态阶段：MCP 现在大致相当于 npm 在 2012–2014 年的野蛮生长期——包数量爆炸，但签名、来源证明、自动审计、统一漏洞数据库这些安全基础设施还没建起来。目前没有统一的 MCP 漏洞库，很多漏洞游离在 CVE 体系之外，也没有标准 SBOM 让你知道一台服务器到底依赖了什么。
第三条是工具属性本身的错配：MCP 服务器不是普通 npm 包。一个包最多污染你的构建产物，而一台 MCP 服务器能读写你的文件系统、执行 shell、访问内网和云元数据服务、使用你的凭证、甚至通过工具描述向 LLM 注入指令。按理它的 security baseline 应该远高于普通包，现实却是更低——这是最危险的一种倒挂。
四、别把它夸大成"下一个 Log4j"
一个负责任的判断必须包含反方视角。有人问：MCP 安全是不是下一个 Log4Shell？答案是——性质相似，量级不同。相似在于三者都有"传递依赖"的供应链属性、权限影响大、且埋在底层不易被发现。但关键差异有三：Log4j 部署在数十亿设备上，MCP 目前只是数万级，差好几个数量级；Log4j 的 JNDI 注入是"发个请求就能 RCE"，门槛极低，而多数 MCP 漏洞需要 Agent 先"被诱导连上恶意服务器"这一步前置；Log4j 几乎波及所有 Java 应用，MCP 只影响用了它的 Agent 系统，受众面小得多。
同样值得记住的还有两点冷静剂：其一，前述高比例来自全量扫描，混入了大量玩具项目，企业精选服务器的实际水位大概率更高；其二，行业已经开始行动——CIS MCP Benchmark（55 条审计建议，覆盖治理、版本管理、传输安全、工具权限）、OWASP GenAI MCP 服务器安全基线、官方沙箱部署指南这三份标准在 2026 下半年集中出台，说明生态已从"意识到问题"进入"制定标准"阶段。但"最终会变好"不等于"现在没问题"：npm 从爆发到安全工具链基本成熟花了 5–8 年，而 MCP 正处在爆发第 2 年、安全基建刚起步的窗口期，接下来 2–3 年的风险是真实的，且这段责任目前只能由使用者自己扛。
五、给正在用 MCP 的团队的分级清单
与其焦虑，不如按风险分层行动。判断投入优先级的标准不是"用了多少台服务器"，而是"这些服务器接触的数据有多敏感"——碰核心数据的哪怕只有一台也值得重点设防，只碰公开信息的多几台也可暂缓。
- 立即做（1–2 周）：盘点 Agent 用了哪些 MCP 服务器；排查是否有暴露在公网且无认证的实例；对关键路径上的服务器做基础检查（已知 CVE、是否暴露 shell、有无输入验证）。
- 中期（1–2 个月）：对关键 MCP 服务器做沙箱化部署（隔离容器、禁止访问云元数据端点、文件系统只读）；建立服务器白名单制度；固定版本号、废除 latest，每次升级做 diff。
- 长期（3–6 个月）：接入 CIS MCP Benchmark 做基线核查；建立持续监控与异常调用告警；把 MCP 纳入整体供应链安全管理体系（SBOM + 签名 + 来源证明）。
六、FAQ
Q1：91.8% 无认证会不会太吓人？我的企业服务器也这么危险吗？
这个比例来自对公网可访问 MCP 服务器的全量动态审计（R2），里面大量是个人 demo 和临时部署，不代表你精心挑选、部署在内网并加了网关的企业级服务器。它的真正警示价值在于说明"MCP 生态的默认安全水位很低"——如果你的服务器是从公共注册表直接拉起的，就要主动补认证和沙箱，而不能假设它出厂就安全。
Q2："静默漂移"和普通软件更新有什么区别？为什么它这么危险？
区别在于它"改了行为却不改身份"。正常更新你会看到版本号和变更说明；而 R3 发现有 40.6% 的服务器在版本间改了对外描述、依赖或端点，标识符却原样不动。因为 MCP 的信任模型是"按名字连接"，你的 Agent 感知不到背后已经换了一台机器、加了一段恶意指令——这正是它比普通更新更危险的结构性原因。
Q3：既然风险这么多，是不是干脆别用 MCP 了？
不必因噎废食。MCP 已成为 Agent 连接企业工具的事实标准之一，完全回避不现实。正确姿势是把它当作一个"权限极大、但安全基线偏低"的高危组件来治理：先用第五节的清单把基础防护（认证、固定版本、沙箱、最小权限）做到位，再随 CIS/OWASP 标准的落地逐步升级到架构级防御。Agent 系统能走多远，取决于它的安全底座有多稳。
参考来源（英文一手材料优先，含完整口径注释）：
- Adversa AI, "MCP Security September 2026: Deadbugz + 3 server CVEs" (2026-09-07)——单月审计发现 68 个可报告漏洞（SQL 注入/SSRF/路径遍历/提示模板注入），附 CVE 编号与 IoC。adversa.ai
- arXiv 2608.00150, "Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale"——91.8% 缺 OAuth、687 个暴露 shell 执行的工具实例、15.2% 高危漏洞占比、41.6% 服务器 3 天内消失。arxiv.org/abs/2608.00150
- arXiv 2609.14119, "Same Name, Different Server: A Security Census of Silent Drift in the MCP Ecosystem" (2026-09-12)——Registry 全量普查 21,643 台服务器 / 72,606 版本记录；51.1% 多版本服务器存在静默漂移、其中 40.6% 标识符未变；漂移者高危漏洞 OR=2.96 (95% CI [2.56,3.42])；Stars 预测力极弱 OR=0.78/log stars；高危率经 414 样本人工校准由 11.1% 修正为 7.6%。arxiv.org/abs/2609.14119
- OX Security, MCP 服务器基础设施安全分析 (2026-09-24)——15,465 台服务器 / 5,095 独立主机名；15.6% 解析至美国以外、2.3% 域名已停解析（可被抢注）、0.45% 位于家庭网络/消费者隧道。ox.security
- Snyk / Koi Security 对 postmark-mcp 事件的披露——首个在野恶意 MCP 服务器：15 个干净版本建立信任后于 1.0.16 投毒（外发邮件 BCC 给攻击者），下架前累计下载 1,643 次。
- CIS MCP Benchmark（55 条审计建议）、OWASP GenAI MCP Server Security Baseline、MCP Project Sandboxing Guidance——2026 下半年集中发布的三份行业标准。（以上中文综述转引自 CSDN《MCP 安全层：五份独立研究揭示的系统性风险与防御路线》，2026-09-25，各原始数据均出自上述英文一手报告）
