5 家机构，同一类缺陷
Ars Technica 在 10 月 5 日报道，独立研究员 Syed Anas Mohiuddin 用约五个月时间，在 Google、JPMorgan Chase、Weaviate、法国 DINUM（data.gouv.fr 的 MCP）、印尼 Tangerang 市政府等互不相干的组织里，确认并推动了同一类 MCP 信任边界缺陷的修复。它们共享的只有协议。研究者把这种跨协议升级叫做「协议枢转」（protocol pivoting）。
攻击链长什么样
攻击者把指令种进某个 agent 会读的内容里——一篇网页、一份文档。这个 agent 并不自己执行危险动作，而是把这段内容当成一条正常的委派任务，转交给它信任的同伴 agent。同伴 agent 处在内网里，于是代表前者发起服务端请求伪造（SSRF）或其他特权动作。毒指令经 MCP 进来，再跨进 A2A 或新兴的 Agent Network Protocol，中间的授权边界就这么丢了。
具体落到的案例
Google 的 MCP Toolbox for Databases 当时缺重定向策略与 IP 校验，被分配了 CVE-2026-14540（CVSS 8.0）：构造路径可把请求引到内部端点。修复方式是加 IP 黑白名单，并在启动时拒绝不安全的 base URL。JPMorgan 的开源 docs MCP 服务器在 fork AWS 代码后丢了 related() 的 allowlist，也已修。Weaviate、DINUM、Tangerang 的类似 SSRF 陆续修复；Rapid7 的 CVE-2026-97228（CVSS 2.7）九月已修。还有五个面向美国联邦机构的 MCP 服务器（含 VA 福利相关）在 9 月 2 日上报，截至报道仍在分流。
怎么理解根因
X41 D-Sec 的研究者更愿意把它看成间接提示注入的一个子类，而非全新品类。根因在于：每个协议都盯着自家前门，没人看走廊——依赖扫描器看不到「以委派文本形式到达的工具参数」。防御上要把每一个 LLM 给出的工具指令当成敌意，校验目标地址，对跨 agent 的敏感事务做授权。和本批 1773 不同，那篇讲的是 Loom 平台自身的代码缺陷；本篇是 agent 之间信任边界被跨协议利用——两者互补，共同说明 MCP/A2A 的护栏不能只装在一端。
修了的与没修的
好消息是，被点名的几家都已修复或正在修；研究者也将在 10 月 23 日的 MCPCon North America 分享细节。但更值得记住的是模式本身：每个协议都看自家前门，没人看走廊。只要 agent 还在靠 MCP/A2A 互相委派，这类跨协议信任缺口就会反复出现，靠单点打补丁填不完。