系统:运行中
← 返回所有攻击
SUPPLY CHAIN MEDIUM NEW

超越工具投毒:恶意远程 MCP 服务器究竟能做什么

2026 年 5 月 21 日的一项研究系统梳理了恶意远程 MCP 服务器在 ChatGPT、Claude Desktop 和 Gemini CLI 上的完整攻击面——同一请求下主机过滤率在 95% 与 50% 之间摇摆,且成功的攻击几乎从不向用户披露。

2026-06-12 // 7 min affects: mcp, chatgpt, claude-desktop, gemini-cli, remote-mcp-servers, smithery

这是什么?

2026 年 5 月 21 日,经同行评审的论文 Beyond Tool Poisoning: Attack Surfaces of Malicious Remote MCP Servers Across LLM Platforms 发表于 Electronics(第 15 卷第 10 期,文章编号 2214;2026 年 4 月 27 日投稿)。由 Anthropic 于 2024 年底推出的 模型上下文协议(MCP) 已成为将 LLM 主机连接到外部工具的事实标准。本文研究的是其 远程 部署模式:用户只需一个 URL 即可添加第三方服务器,这会悄无声息地把主机的大部分攻击面转移到由匿名方运营的基础设施上。

此前大多数 MCP 安全研究关注 工具投毒攻击(Tool Poisoning Attack,TPA)——隐藏在工具 描述 中、在注册时劫持模型的指令。本文认为描述只是威胁空间的一角,并围绕一个更有用的问题重新组织该问题:主机 LLM 是否参与产生恶意结果?

工作原理

作者将恶意服务器的行为分为两类,并针对 ChatGPT、Claude Desktop 和 Gemini CLI 测试了五个场景。

类别            攻击在何处完成                      评估的场景
-------------   -------------------------------   ----------------------------------------
LLM-passive     在服务器内部完成,仅使用主机          File Content Exfiltration
                派发的参数。LLM 的内容推理            Email Content Exfiltration
                从不接触恶意行为。

LLM-active      LLM 是投递通道。服务器诱导            Conditional URL Substitution
                模型产生/转发载荷,途径为工具          Malicious Code Augmentation
                的 描述(C1)或其 响应(C2)。        Image Steganography

这种划分很重要,因为 关键的防御边界因类别而异。对于 LLM-passive 攻击,唯一的防御是对主机发送给工具的数据做 调用前过滤——参数一旦发出,模型便无法干预。对于 LLM-active 攻击,边界在于模型自身的 内容推理:它是否把工具描述视为权威,以及是否在转发前校验工具响应。

每个结果用两个指标衡量:攻击成功率(ASR),以及针对成功试验的 自我报告率(SRR),后者反映一次成功攻击对细心用户是否仍然可见,还是悄然完成。其现实动机并非假设:论文引用了 2025 年 9 月的一起事件——一个非官方的 Postmark MCP 服务器(每周下载量超过 1500 次)被其维护者修改,将每一封外发邮件静默密送(BCC)至攻击者地址,数周未被发现。

为什么重要

三个发现尤为突出,每一个都动摇了一种令人安心的假设。

第一,主机侧过滤在各厂商之间极不一致。对于同一封携带凭据的发邮件请求,Claude Desktop 的 ASR 为 95%,而 ChatGPT 为 50%(95% Wilson 置信区间不重叠)。ChatGPT 倾向于直接拒绝,或在转发前把凭据替换为 [REDACTED];同样的请求在其他主机上却畅通无阻。「这安全吗?」没有可移植的答案:取决于你用的是哪个主机。

第二,决定成功的是通道,而非技术。基于描述(C1)的攻击只在 URL 替换上可靠奏效,而基于响应(C2)的攻击——藏在工具 运行时返回内容 中的载荷——在全部三个 LLM-active 场景中成功,ASR ≥ 85%。运行时的工具输出才是防护不足的攻击面,而现有工具链却仍主要审查描述。

第三,也是运营上最令人担忧的:成功的攻击几乎从不向用户披露。在所有 LLM-passive 攻击和大多数 LLM-active 配置中,SRR 均为 0%。唯一的例外是 Claude,在基于响应的代码增强中,它在 100% 的成功试验里报告了被插入的载荷——这表明透明性是可实现的,只是尚未系统化。

防御

没有单一控制能覆盖这一攻击面;论文主张分层防御,每一层对应上文的一个类别。

  • 主机侧调用前过滤 是对抗 LLM-passive 外泄的 唯一 防线。在参数发送到任何远程工具之前,剥离或脱敏其中的机密(凭据、令牌、个人数据),并对外发数据采用默认拒绝。
  • LLM 层面的响应审计 是遏止高 ASR 响应通道的关键。把工具 响应 视为不可信输入——而不仅仅是描述——并在转发前依据用户的真实请求校验返回内容。
  • 用户可见的输出透明性 是横向的兜底措施。展示运行了哪个工具、它收到了哪些数据,以及模型对其回答做了哪些修改,让静默的成功(SRR 0%)不再静默。
  • 运营层面:把远程 MCP 服务器视为进入你信任边界的第三方代码。固定并审查服务器,而非凭 URL 安装;警惕维护者的「rug-pull」式变更;优先选择经过审核的注册表,而非开放聚合站。

这些措施与 MCP 基准(如 MCPTox)以及更广泛的生态综述(如 Beyond the Protocol)所提出的分层指引相一致。

状态

这是已发表的学术研究,评估的是按实际部署运行的商用主机,而非单一厂商的 CVE。这些行为是远程 MCP 作为一种设计范式的固有特征,而非可打补丁的缺陷;因此上述缓解措施是架构性的。关键日期:MCP 于 2024 年底推出;Postmark 事件发生于 2025 年 9 月;论文于 2026 年 4 月 27 日投稿、5 月 21 日发表。各平台的过滤行为可能随厂商更新主机而变化——持久的教训在于平台间的差异。

Sources