MCP 或许是你没听说过的、风险最高的 AI 智能体间通信协议

Ars Technica 新闻

摘要

研究人员在 Model Context Protocol(MCP)中发现了结构性信任缺口漏洞,攻击者可借此在 AI 智能体之间传播恶意提示注入,相关漏洞已在 Google、Rapid7、JP Morgan Chase 等公司披露。

<p>数百万组织正在采用 AI 智能体,这为攻击者创造了新的机会,让他们能够诱导智能体执行恶意操作,例如窃取数据库内容以及敏感的商业和个人信息。</p> <p>在过去五个月中,Google 和其他四家组织——除了使用 AI 智能体之外几乎毫无共同之处——均已承认存在相关漏洞:攻击者可以利用目标网络内的某个智能体,将恶意指令传播给内部的其他智能体。这是一种特殊形式的提示注入(prompt injection),其攻击目标不是 LLM,而是某个特定的智能体,例如翻译或数据分析智能体。这类智能体内部的防护机制(如果存在的话)往往不够严格,会将指令继续传递给链条下游的其他智能体。由于后者明确信任前者,便会遵照这些指令执行。</p> <h2>出乎意料且难以缓解</h2><p>独立研究员 Syed Anas Mohiuddin 测试了包括 Google、JP Morgan Chase、Weviate、Rapid7、法国政府跨部门数字管理机构以及美国联邦政府在内的多家组织的智能体。他的概念验证攻击利用了 <a href="https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro">Model Context Protocol</a>(简称 MCP)中的信任缺口。该协议是 AI 应用和智能体在内部网络中相互通信的一种方式。下方示意图展示了一个简化的 MCP 工作流程。</p><p><a href="https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/">阅读全文</a></p> <p><a href="https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/#comments">评论</a></p>
查看原文
查看缓存全文

缓存时间: 2026/10/05 23:38

# 面向智能体间通信的 MCP,可能是你从未听过的风险最高的协议 来源:https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/ 跳转至正文 (https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/#main) 新协议中的信任缺口会让恶意提示词从一个智能体扩散到另一个智能体。 数以百万计的组织正在采用 AI 智能体,这为攻击者提供了新的机会,让他们得以驱使智能体执行恶意操作,例如窃取数据库内容以及敏感的商业和个人信息。 过去五个月里,Google 及另外四家组织——除使用 AI 智能体外并无多少共同之处——均已承认存在漏洞,攻击者可以利用这些漏洞,通过目标网络中的一个智能体将恶意指令传播给其他内部智能体。这种技术是一种特殊形式的提示词注入(prompt injection),其攻击对象不是大语言模型(LLM),而是某个特定的智能体,例如翻译或数据分析智能体。此类智能体内部的防护机制(如果存在的话)往往十分宽松,会将这些指令沿链条传递给下游的其他智能体。而后者明确信任前一个智能体,因此会遵照执行。 ## 出人意料且难以缓解 独立研究员 Syed Anas Mohiuddin 测试了包括 Google、JP Morgan Chase、Weviate、Rapid7、法国政府跨部门数字主管机构以及美国联邦政府在内的多家组织的智能体。他的概念验证攻击利用了 MCP(Model Context Protocol,模型上下文协议,https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro)中的信任缺口。该标准是 AI 应用与智能体在内部网络中相互通信的方式之一。下图展示了简化的 MCP 运作示意图。 [](https://cdn.arstechnica.net/wp-content/uploads/2026/10/model-context-protocol-diagram.webp) 许多专用智能体缺乏本可缓解提示词注入最严重后果的防护机制。而且由于 MCP 服务器为每个智能体存储凭据,智能体也被设计成信任所有其他内部智能体,因此本会被 LLM 拒绝的攻击得以成功。在许多情况下,精心构造、针对正确智能体的提示词会导致[服务端请求伪造(SSRF)](https://en.wikipedia.org/wiki/Server-side_request_forgery),这是一种迫使 Web 服务器发起未授权网络请求的漏洞。 "AI 智能体为攻击者提供了一组全新的连接通路,可以借此横向渗透,"Rapid7 漏洞情报总监 Douglas McKee 告诉 Ars,"有人在内容中埋下文本,某个智能体读到后会将其当作普通的委托任务转发给另一个智能体,而后者因为信任派活给自己的一方就会去执行。这条链条上的每个环节都做了设计上该做的事,这正是此类攻击难以察觉的原因。每个协议都假设自己是独立存在的,因此每个协议都只检查自己的大门,却没人看管它们之间的走廊。" Mohiuddin 在 Rapid7 网络中发现的漏洞 CVE-2026-97228,其严重性评分仅为 10 分制下的 2.7 分。Rapid7 于上个月修复了该漏洞(https://www.rapid7.com/db/vulnerabilities/cve-2026-97228/)。 影响 Google 的漏洞更为严重,评分为 8 分。该漏洞源自一个面向数据库的 MCP 工具箱(googleapis/mcp-toolbox)在初始化其 HTTP 客户端时未启用 CheckRedirect 策略——这是一组用于控制服务器在 URL 返回错误或重定向到其他 URL 时应如何处理的设置。Google 的 HTTP 客户端也未能验证目标 IP 地址。 "精心构造的路径参数可能使该工具箱跟随重定向访问内部端点,并以攻击者的名义发送请求,"Mohiuddin 解释道(https://anas-security-portfolio.vercel.app/protocol-pivoting-update.html)。Google 的修复方案采用了 IP 段白名单和黑名单。"它在启动时就拒绝不安全的基地址 URL,而不是等到首次请求时才处理。这才是真正的 SSRF 防护该有的样子。而且这比大多数 MCP 服务器所做的工作要多得多。" Mohiuddin 将这一类攻击称为"协议转向"(protocol pivoting),因为当应用程序或服务器使用 MCP 将任务分配给某个智能体,而该智能体随后通过另一种通信方式(例如 Google 的智能体间协议 Agent-to-Agent,即 A2A 协议,用于智能体之间的委托;或是正在兴起的智能体网络协议等新标准)将恶意指令转发给另一个智能体时,这类漏洞便可得逞。他说,信任或授权往往在翻译过程中悄然丢失。他将协议转向描述为"一种多步攻击:攻击者先通过一种协议获得初始访问权限,然后利用不同协议之间的信任假设,最终提升到只有通过另一种协议才能获得的能力"。 X41 D-Sec 的研究员 Markus Vervier 也曾设计过利用 MCP 发动的 AI 攻击(https://arstechnica.com/information-technology/2026/05/millions-of-ai-agents-imperiled-by-critical-vulnerability-in-open-source-package/),他认为更恰当的术语仍然是"提示词注入",Mohiuddin 的技术只是其中的一个简单子类。 "在我看来,这就是间接提示词注入,"他告诉 Ars,"恶意提示词可以来自另一种协议(例如 A2A),并在通过另一种协议使用时才显现出来,这一点并不是此类攻击成立的严格必要条件。当然,这种情形出人意料,且通常难以缓解。" 值得注意的是,这一转向技术在五家除了都使用 MCP 之外毫无共同点的组织中都奏效了。MCP 还很新,却在得到充分测试和加固之前就已经无处不在。各组织在争相构建庞大的智能体架构时,已经抛弃了一项核心安全原则——零信任。在该模型下,网络的构建前提是假设一个或多个节点可能已被感染。为了缓解由此带来的影响,工程师必须设计节点,使其在与其他节点进行敏感交易之前要求授权验证。 "我希望人们从中吸取的教训是:任何从 LLM 传递给你的工具的内容,都应该像来自互联网上陌生人的输入一样对待,因为在提示词注入场景下,它恰恰就是如此,"McKee 说,"底下的漏洞都是老朋友,比如注入和 SSRF,20 年来修复方案一直没有变化。要给这位研究员点赞,因为他为这类攻击起了一个名字,而有了名字,防御者和标准制定机构才会真正着手为它设计对策。" Dan Goodin 的照片 (https://arstechnica.com/author/dan-goodin/) Dan Goodin 是 Ars Technica 的资深安全编辑,负责监督恶意软件、计算机间谍、僵尸网络、硬件破解、加密和密码等领域的报道。业余时间他喜欢园艺、烹饪以及关注独立音乐圈。Dan 常驻旧金山。在 Mastodon 上关注他(https://infosec.exchange/@dangoodin)或在 Bluesky 上关注他(https://bsky.app/profile/dangoodin.bsky.social)。可通过 Signal 联系他:DanArs.82。 20 条评论 (https://arstechnica.com/security/2026/10/vulnerability-in-agents-from-google-and-others-exposes-structural-flaw-in-mcp/#comments) 1. 最受关注文章的配图:俄罗斯宣布大规模隔离,此前一位鼠疫研究者死因不明 (https://arstechnica.com/health/2026/10/researchers-death-from-undisclosed-illness-sparks-mass-quarantine-in-russia/)

相似文章

GetMCP:AI 代理的零信任

Reddit r/AI_Agents

GetMCP 是一个可自托管的开源工具,通过提供每请求审计、每代理撤销、策略执行和 API 调用的人工介入审批,为 AI 代理带来零信任安全。它根据 OpenAPI 规范生成 MCP 服务器,并作为具有防篡改审计日志的流式代理运行。

到2026年,哪些MCP服务器能让AI代理具备真正的业务能力?

Reddit r/AI_Agents

一位实践者分享了他们在业务工作中使用MCP(模型上下文协议)服务器的经验,详细介绍了哪些服务器提供真正的读写能力(例如Postgres MCP、HubSpot MCP、PostFast)以及哪些令人失望(例如Slack MCP、Google Ads MCP),同时强调了主要的安全问题,如OAuth采用率低和漏洞率高。

@swyx: 解释一下

X AI KOLs Following

本文介绍了用于构建可插拔AI代理架构的模型上下文协议(MCP),详细介绍了在Sentry构建MCP服务器的经验教训,包括OAuth 2.1集成、设计对代理友好的工具接口以及当前生态系统的局限性。

MCP 一直是个糟糕的主意吗?

Simon Willison's Blog

文章主张,尽管有观点认为全编程代理已使 MCP 过时,但 MCP 在 AI 代理系统中依然重要,能够提供控制、身份验证、用户界面和审计日志功能。