如果要挑一件事，代表 2026 年 9 月 MCP 安全的真实水位，那大概是 Deadbugz 这场供应链接行动。一个 GitHub 账号，在 74 分钟里向互不相干的 AI 与开发者工具项目发了 23 个拉取请求，每个都打包一个看着人畜无害、用于文本格式化或摘要的 MCP 服务器。审查方在合并前检查它，发现一切正常——因为那时它确实一切正常。这个服务器在前三次工具调用里，行为完全符合宣传；只有在此之后，它的元数据才会自我改写成猎取 SSH 密钥、云凭据、shell 历史与 Kubernetes 配置指令，还对运行它的用户隐蔽。
这种构造，从设计上就绕开了「一次性审查」。绝大多数组织今天的标准做法，是在批准一个新 MCP 服务器之前扫描一次；可 Deadbugz 的 payload 在扫描时刻根本不存在，它只在服务器被信任、被连接、被用过之后才出现。研究者由此得出的实务结论很明确：要在批准之后持续盯工具元数据的变化，并在客户端缓存时每次重连都比较工具定义，因为事后漂移，才是一次性审计抓不到的信号。
更该警惕的，是「调用方」变了
同一批披露的还有三起 MCP 服务器 CVE，它们共同印证了一个被低估的真相：眼下 MCP 出问题的地方，大多和模型怎么推理无关。CVE-2026-73498 是 Atlassian Confluence 的附件上传函数把客户端给的文件路径直接送进文件打开调用、毫无校验，任何已认证客户端都能读到服务器进程能触及的任意文件；CVE-2026-67357 是 ArcadeDB 的一个经 MCP 暴露的设置工具把高可用集群令牌以明文返回，凭这一个令牌就能冒充 root；CVE-2026-19956 是某个 Facebook Ads 的 MCP 服务器在分页函数里存在服务端请求伪造，让已认证调用者借服务器自身网络位置发请求。三起漏洞，分别是一个路径穿越、一个密钥处理失误、一个 SSRF——都是普通 Web 安全周报里常见的老面孔。
这三起 CVE 之所以值得单列，是因为它们把「智能体安全」和「传统应用安全」之间的断层摆上了台面。过去我们习惯把 AI 风险想象成模型 hallucinate 或 prompt 被注入，可 MCP 暴露出来的问题，几乎全在传统软件漏洞的范畴里：文件路径没校验、密钥没管好、出站请求没限制。区别只在于，这些被暴露的接口现在站在一个会自主决策、会批量调用的智能体身后。换句话说，上智能体之前，先把普通应用安全的老账还清，比急着买一套「AI 安全」新方案更划算——底子没补，再智能的编排也只是在更宽的攻击面上跑更老的错误。
变的不是漏洞类型，是调用方。一个 MCP 服务器，把普通的业务逻辑暴露给一个非同寻常的调用者：它能在机器速度下、不知疲倦地、成千上万次一致地发起工具调用。同样一个人类测试者可能碰巧才踩到的 bug，到了智能体手里，成了它奔向既定目标的例行一步。更麻烦的是横向扩散：已有研究记录过跨服务器级联效应，攻陷一个服务器后向工作流里其他服务器传播的速度高于七成，意味着单个坏服务器的爆炸半径很少停留在它自己身上。对企业更现实的提示是：先把连进来的每个 MCP 服务器，按「未校验的文件路径、在工具输出里回吐的密钥、未校验的出站请求」这三类去审一遍，再把静态密钥往 OAuth 2.0 上迁，最后把检查放到批准之后而非之前。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。