2026 年 10 月的第一周，独立安全研究员 Syed Anas Mohiuddin 发布了一份研究报告，里面的数字让人不安：Model Context Protocol（MCP）服务器中的同一个漏洞，已经被 Google、摩根大通（JPMorgan Chase）、Weaviate、法国部际数字事务总局（DINUM）以及印度尼西亚 Tangerang 市政府 的安全团队确认并修复。两个 CVE 已经发布。美国联邦系统的 MCP 服务器里还有五个发现处于 open 状态。
这不是“某家厂商代码写得烂”的故事。这是一个关于信任的故事——在智能体流水线里，谁信任谁，以及这种信任能让攻击者做什么。
同一周浮现的两个信任问题
问题一：服务器信任智能体提供的 URL。 Mohiuddin 十月的更新标题叫“Protocol Pivoting, four months later”，验证的是他在 2026 年 5 月做出的一个预测：如果这个弱点是结构性的，而不是某一次粗心的实现，那么同一个 bug 会出现在彼此没有任何代码、行业、国家、归属关联的团队写出的服务器里。结果真的出现了。这个失效模式是服务端请求伪造（SSRF）：MCP 服务器拿智能体提供的 URL、路径或端点直接组装出站请求，不校验它到底解析到哪里——于是智能体实际上决定了服务器的网络身份去跟谁说话。
Google 的案例最严重，严重程度 8/10。它的数据库 MCP 工具箱在初始化 HTTP 客户端时没有重定向策略，也不校验目标 IP 地址。一个精心构造的路径参数就能让工具箱跟随重定向到内网端点，替攻击者发请求。Google 的修复很有启发性：IP 段 allow-list 加 block list，在启动时就拒绝不安全的 base URL，而不是等到第一次请求发出去。
问题二：智能体互相信任对方的消息。 本周另一个 PoC 演示了多智能体网络内部的信任链缺口：攻破一个智能体，就能把一条可疑指令——LLM 本来会拦截的那种——伪装成可信内部消息一路转发。它一路畅通，因为下游每个智能体都信任这次交接。
Rapid7 漏洞情报负责人 Douglas McKee 对 Ars Technica 说得很直白：“有人在内容里种一段文本，智能体读到之后把它当成正常的委派任务传给另一个智能体，第二个智能体就执行了，因为它信任交活的人。链条上的每一环都完全按设计做了自己该做的，这恰恰是它难抓的原因。每个协议被造出来时都假设自己是独居的，所以每个都只看自家前门，没人盯楼道。”
为什么这是结构性的，不是 bug
Mohiuddin 把这一模式总结成一份 IETF Internet-Draft（draft-mohiuddin-mcp-security-considerations-00），用一个名字统摄六类漏洞：protocol pivoting（协议跳板）——攻击者从面向模型的协议进入，跳板到服务器身后能触及的一切。用他的话说，根本假设是“穿过 MCP 边界的数据是可信的，因为它来自系统内部”。在智能体流水线里，这个假设不成立。
规模也佐证了他的判断。学术界的 MCPInspect 研究（在 DSN 2026 上发表）做了一个集成前扫描器，发现了 833 个存在漏洞的 MCP 服务器——其中 18 个的工具描述可疑或有误导性，疑似有人在供应链层面故意投毒。这不只是意外暴露，生态的某些角落正在被主动播种。
大多数报道跳过的问题：被毒化的指令到底能做什么？
这是对所有基于 MCP 构建的人来说最关键的部分。同一条被毒化的指令，到达两个不同的服务器：
- 服务器 A 暴露了写工具：转移资金、修改记录、经由上面的 SSRF 调用内网端点、通过日志外泄数据。
- 服务器 B 只暴露只读数据查询：最坏情况是一个错误答案，或一次浪费的 API 调用。
协议漏洞一模一样，爆破半径却是设计决定的。 补丁堵的是今天的洞；工具设计决定的是下一个洞的代价。官方 MCP 安全最佳实践（2026 年 7 月）和 NSA 指引（2026 年 6 月）都落到同一个结论：纵深防御、最小权限——并且明确写了拆分读写工具。
给运营者的一周 checklist
如果你在生产环境跑智能体，这份短清单值得现在就做：
1. 把每一条工具输出都当不可信输入——尤其是在消息要在智能体之间跳转的多智能体架构里。
2. 不要让不同厂商的智能体共享同一套部署。 网格里任何一个智能体沦陷，就能替整个网格说话。
3. 拆分读写工具，最小化 scope，任何有副作用的操作都要用户显式确认。
4. 给 MCP 服务器加上出口控制——代理、allow-list。Google 的修复就是模板：在启动时拒绝不安全目标，而不是等请求发出去。
5. 接入前锁定版本、预扫描服务器，警惕工具描述与实际行为不符的。
6. 记录完整链条——prompt → 工具调用 → 下游动作——出了事能复盘，而不是靠猜。
我们的姿态：设计上只读
我们做的就是 Pangolinfo Amazon Data MCP 服务器，所以我们的位置说清楚：
- 只读。 所有工具都是严格只读的数据查询——商品、搜索、评论、卖家、类目数据。没有任何一个能写亚马逊、下单、发评论、改 listing，或在第三方平台做任何有副作用的动作。
- 自带密钥（BYOK）。 你的 API 密钥只从本地客户端配置读取，只发往 Pangolinfo 的主机，走 TLS 1.2+。我们不集中存任何别人的凭证。
- 无遥测，不收 PII。 服务器不回传、不记你的 prompt、不存账户信息。
- 开源（MIT）。 任何人都能审计服务器发了什么、发到哪里。私下报告问题：[email protected]。
完整的安装说明和工具手册，见 Amazon Data MCP 文档。
信任链这一点，直接说：MCP 智能体默认互信——独立研究已经证实（2026 年 10 月），被攻破的智能体能把恶意指令伪装成可信内部消息转发。我们的暴露面是设计上限死的：经由这个服务器的毒化指令写不了、交易不了、够不到第三方服务。如果你跑多智能体，把工具输出当不可信输入，别跟别家厂商的智能体共享一套部署。
一句诚实的话：只读限定的是爆破半径，防不住数据完整性攻击。上游被攻破照样能返回假数据，这一点任何服务器端设计都修不了，只能靠带外验证。与其卖银弹，不如把话说直白。
结论
审计你跑的 MCP 服务器。默认信任链还会再给你“惊喜”——研究员们几乎是实时地在告诉我们它会。再有，设计你造的工具时，让“惊喜”的代价是一个错误答案，而不是一个错误动作。
— Pangolinfo 团队
来源
- Unite.AI — “Researcher Discloses Same MCP Flaw at Google, JPMorgan, Two Governments”：https://www.unite.ai/researcher-discloses-same-mcp-flaw-at-google-jpmorgan-two-governments/
- Real Hacker News（转述 Ars Technica）— “MCP for agent-to-agent comms may be the riskiest protocol you’ve never heard of”：https://realhacker.news/mcp-for-agent-to-agent-comms-may-be-the-riskiest-protocol-youve-never-heard-of/（Ars 原文：https://arstechnica.com/security/2026/10/ai-agent-frameworks-trust-chain-is-broken-rapid7-researcher-warns/）
- Syed Anas Mohiuddin（dev.to）— “Four vendors, one bad assumption: SSRF in MCP servers”：http://dev.to/syedanas01/four-vendors-one-bad-assumption-ssrf-in-mcp-servers-48ii
- AI Daily Post — “MCP Agent Protocol Flaw Exposes Chain-of-Trust Risk”：https://aidailypost.com/news/mcp-agent-protocol-raises-chain-of
- Forkast — “MCP Security: Attack Surface, CVEs, and Mitigations”：https://forkast.news/glossary/mcp-security/
