文章总结： 文章揭示MCP服务器成为AI供应链安全黑洞：一个月发现68个CVE，91.8%的MCP服务器缺少OAuth认证。四类高危漏洞包括SQL注入、SSRF攻击云元数据、提示模板注入和路径遍历，可致数据泄露和智能体劫持。工具输出可能被注入恶意指令，命令分类缺陷可打穿审批门禁。建议立即盘点资产、排查漏洞、网络隔离、更新尽调问卷、接入监测并对照安全基线。
综合评分： 88
文章分类： 漏洞分析,供应链安全,应用安全,安全建设

一个月 68 个 CVE、91.8% 没有 OAuth：你的 AI 工具层正在裸奔

原创

欢迎关注→
欢迎关注→

安全客

2026年9月21日 08:18
湖北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

一个月审出 68 个 MCP 服务器漏洞，91.8% 连 OAuth 都没有，AI 工具层成了新的供应链黑洞。

上周做资产盘点，业务的人问我：”我们上了智能体，那个 MCP 归谁管？”我在 CMDB 里搜了半天，一条记录都没有。不在主机清单，不在 API 资产表，不在外包台账，甚至不在那份写得很厚的 AI 供应商尽调问卷里。可它天天在跑，手里攥着云凭证和数据库连接串。

眼下的问题就一句话：你的 AI 智能体的”工具层”，正在变成没人管的新供应链。

68 个洞，不是”某一家厂商倒霉”

9 月 7 日，安全公司 Adversa AI 发了一份 MCP 安全汇总报告，标题是《MCP security September 2026: Deadbugz + 3 server CVEs》。里面给了一个不太好看的数字：在他们审计的 MCP 服务器里，累计发现 68 个可报告漏洞。

报告点名了具体 CVE 编号，还关联了一个代号 Deadbugz 的攻击活动。9 月 11 日，AI Governance Institute 跟进发文，标题直接用了”系统性缺口”这个词，不是”偶发问题”的写法。

为什么说系统？Adversa AI 之前还有一组数据：审计过的 MCP 服务器里，91.8% 缺少 OAuth 认证。十台设备九台没装门锁，那 68 个洞一点都不意外。说白了是欠账，不是运气。

四种漏洞，每一种都能直接掏家底

报告里归了四类，都是老熟人，但放进 MCP 场景里，杀伤力变了。

SQL 注入。经典中的经典，参数没过滤、拼接执行，攻击者顺着工具调用直接把后端库读穿。

服务端请求伪造（SSRF），而且专门盯着云元数据服务打。这条最要命。SSRF 不稀有，可一旦打的是云厂商的元数据端点，拿到手的往往不是普通数据，是云上的临时访问凭证。凭证一到手，权限就不止”某个 MCP 服务器”，是你云上那一片。

提示模板注入（prompt template injection）。攻击者把指令塞进模板里，让 AI 智能体按他的意思去调工具、读文件、往外发数据。

路径遍历。../../ 那一套，越过边界读到本不该读的文件。

报告说得很直白：以上每一类，都能导致数据外泄、凭证被偷，或者在真实的企业部署里直接劫持 AI 智能体。不是理论推演，是已经在跑的环境。

91.8% 没有认证，这事怪不到开发者头上

很多人第一反应是”开发者太糙”。我不完全同意。

MCP 本来就是从”先跑通再说”长出来的。Model Context Protocol，Anthropic 提的开放协议，把 AI 助手接到外部工具上，Claude Desktop、Cursor、Windsurf、VS Code Copilot 都在支持。这半年生态野蛮生长，比的是”接了多少工具”，没人比”认证做得怎么样”。这笔账现在要还，还得在别人的时间表上还。

连工具返回的东西都不能当数据看

如果说漏洞是明面上的病，下面这条更像慢性中毒。

针对 19 个 MCP 服务器的相关研究发现，工具输出会例行向 AI 智能体的上下文里注入意外指令。其中 Context7 被披露存在具体的提示注入问题。9 月 2 日 Digital Applied 的审计也指向同一件事。

这条结论反直觉，但每个做安全的都该记住：**你不能默认 MCP 服务器的输出是可信数据。**传统架构里，数据就是数据，接口返回什么我当值处理；到了智能体架构，接口返回的东西会被模型当指令读。一个被污染的工单标题、一条被构造的日志，就可能变成给 AI 下的一张命令。

再往下一层是审计日志。智能体读的是被人塞过的内容，它做的事、调的工具全被记下来，这份日志还能不能当合规证据？数据保护这条线上，这是直接踩线。

审批门禁，也可能是纸糊的

9 月 4 日有一份关键公告，讲某 SSH MCP 服务器的实现有命令分类缺陷：一条命令被归类成”安全”，但远程 shell 实际执行的，是另一条权限更高的命令。

这个缺陷的可怕之处不在技术难度，在于它直接打穿了企业审批门禁所依赖的只读工作流假设。我们做审批的逻辑是”只读放行、写操作拦住”，靠的就是分类这一层。分类一旦不可信，所有审批都是形式主义。

所以命令分类、服务器来源、审批流程，得当成三个独立验证的控制点，不能串成一条链子相互背书。

好消息是行业基线在补。9 月 10 日，云安全联盟（CSA）更新指南，明确把 MCP 服务器认证流程确立为企业智能体部署中的安全关键控制点：远程服务器连接必须使用 OAuth 2.1 + PKCE，并且在任何认证动作开始之前，强制做服务器元数据校验。指南点名批评的，就是薄弱的服务器发现机制，和对服务器提供端点的无批判信任，这两条被认定为元数据操纵和未授权工具交互的主要攻击入口。

别等 CISA 把你写进 KEV，今天先干这六件事

1.盘点。把所有 MCP 服务器捞出来，第三方和开源的也算，塞进资产台账。搞清楚谁在用、连了什么、能不能出网。

2.挨个查那四类洞。SQL 注入、SSRF、路径遍历、提示模板注入，对着过一遍，别抽样。

3.网络层隔离。最便宜也最见效的一步：让 MCP 服务器进程碰不到云元数据端点，先把 SSRF 这条路堵死。

4.改尽调问卷。认证机制、输入校验、补丁节奏，都加进 AI 供应商风险评估。模型和平台你都评了，不多这一页纸。

5.接进已有的监测流程。让它跟着现有 CVE 跟踪一起走，别飘在流程外。顺便盯这些 CVE 会不会被 CISA 列进已知被利用漏洞（KEV）目录，一旦进了，联邦合同相关组织就得按强制时限修。

6.对基线。拿 OWASP GenAI 的 MCP 安全基线和 MCP 沙箱基线当尺子，量出自己的差距清单。监管方和审计方已经开始引用它们当最低标准了。

总结

这轮 MCP 的 68 个洞，不会因为今天没人爆出大事件就消失。它们躺在你在用的那些服务器里，安静地等着。

评估模型我们问得很细，评估智能体平台也问得很细，唯独它们脚下那层 MCP 服务器，一张问卷都没人发。

把清单拉出来吧。智能体有多聪明是后话，先弄清你手上那根管子归谁管。