引言
2024年11月，Anthropic发布了模型上下文协议（Model Context Protocol, MCP），这是一个开放标准，旨在让大模型应用与外部工具和数据源建立双向连接。MCP的诞生为大模型与外部世界交互提供了统一的接口，截至2025年6月，三个主流聚合平台：Smithery.ai，MCP.so，Glama.ai 展示的服务器总数已超25000个。
MCP架构示意图（图源：Norah Sakal）
然而，当LLMs拥有了连接整个数字世界的能力时，一个关键问题也随之浮现——如何确保MCP所连接的每一个服务器都是安全、可信的？倘若其中混入了恶意MCP服务器，又会对用户造成怎样的影响？
针对上述问题，蚂蚁天象实验室联合四川大学、中山大学、电子科技大学、浙江大学联合公布研究《Beyond the Protocol: Unveiling Attack Vectors in the Model Context Protocol Ecosystem》。
论文链接：
https://arxiv.org/abs/2506.02040
主要发现
1. 主流MCP聚合平台缺乏严格的审核机制，为攻击者上传恶意服务器创造了条件；
2. 用户在识别和分析恶意MCP服务器方面存在显著困难；
3. 现有常见LLM模型难以抵御MCP层面发起的注入攻击；
4. 用户对MCP所带来的新型安全问题认识不足；
5. MCP应用的安全机制不合理，使用者出现了报警疲劳现象；
6. MCP聚合平台/提供者的责任划分不明确，一旦造成安全事故追责困难；
7. 基座大模型对工具调用存在固有信任。
我们依据下图数字标号所代表的交互路径，分类总结了四种MCP生态系统中的新型攻击向量。
图注：MCP工作流
1
工具中毒攻击
（Tool Poisoning Attack）
攻击者在MCP服务器的工具描述中嵌入用户难以注意的恶意指令，这些隐藏指令通过欺骗或注入的方式导致使LLMs输出不可信的结果，或窃取用户预定义的敏感信息。该攻击主要影响路径②->④，在路径⑥期间成功利用。
2
傀儡攻击
（Puppet Attack）
在多个MCP服务器共存的环境中，恶意服务器通过精心设计的工具描述对LLMs实施提示注入，以影响LLM代理进行工具调用的决策过程。用于攻击的服务器A通常无需被直接执行，而是在服务器能力注册的初始化阶段②以及④->⑤影响LLM代理，在路径⑥期间成功利用。
3
供应链攻击
（Rug Pull Attack）
“Rug Pull”常见于加密货币领域，即诈骗者发行新代币，集资后卷款潜逃，可以通俗的称之为“杀猪盘”。由于目前很大一部分MCP服务器的配置都是通过`npx/uvx -y package-name@latest`的方式进行的，方便维护和更新的同时，也引入了这种类似于Rug Pull的供应链攻击隐患。恶意服务器最初提供看似合法的服务以获得用户信任，在一段时间后改变行为。这种攻击主要借助路径①->②->④，在路径⑥期间实施攻击。
4
恶意外部资源攻击
（Exploitation via Malicious Resources）
恶意MCP服务器将代理重定向到有害的第三方服务资源，这些资源位于MCP生态系统之外，可以是攻击者设置的API或写入了有害内容的网页，主要影响路径⑦->⑧、④->⑤（链式调用），在路径⑦成功利用。
值得注意的是，即使是非恶意的MCP服务器，例如Browser-use、Github-MCP等，若未正确的进行安全检测和内容过滤，也同样可能遭受这种攻击。
为了验证上述攻击可行性，我们从聚合平台、终端用户、大模型工具三个必要攻击阶段出发，设计如下三个实验。
问题一：攻击者能否成功将恶意MCP服务器上传至聚合平台？
我们构建了一个包含模拟恶意代码和恶意说明的测试MCP服务器，并在三个平台成功上传了该模拟恶意服务器。
图注：上传成功的模拟恶意服务器页面网页快照
图注：Glama展示为默认的”safe to use“（安全使用），具有很大的误导性
这表明，现有的MCP聚合平台缺乏严格的审核机制，攻击者可轻易上传恶意服务器。
问题二：用户能否识别出恶意MCP服务器？
为了进一步研究用户是否能够意识到并识别出恶意MCP服务器，我们开发了一个模拟平台，在其中展示了13个MCP服务器（其中4个为恶意），通过20名参与者的模拟实验和半结构化访谈来评估用户识别能力。
图注：模拟MCP聚合平台展示
图注：Google Analytics（GA4）记录的
平台事件触发路径
调研发现，75%的参与者至少选择了一个恶意MCP服务器，仅有1名参与者成功识别出所有4个恶意MCP服务器，这表明，用户在识别和分析恶意MCP服务器方面存在显著困难。
问题三：恶意MCP服务器能否在用户本地环境中成功执行有害行为？
我们构建了包含三种典型攻击向量的实验框架，并在五款主流LLMs上进行实测，评估攻击成功率和拒绝率。
图注：傀儡攻击PoC示意图
图注：实验结果展示
实验结果表明，当前的主流LLMs缺乏有效抵御这些恶意MCP攻击的机制。
研究总结了MCP生态系统现有的四个关键安全挑战：
用户对MCP安全问题的认知不足
即使是有安全和开发经验的参与者，对MCP配置、工具描述和运行时存在的Prompt注入等新兴攻击向量也缺乏了解和关注。更糟的是，有45%的参与者表示考虑应用LLMs+MCP的方式处理敏感数据，如个人笔记和代码等，这进一步放大了潜在风险。
用户对安全警告的脱敏和疲劳
45%有MCP实际使用经验的参与者承认在初次使用后，会忽略详细检查警告对话框、权限请求和操作细节。此外，参与者提到在使用Cursor和Cline等MCP应用时通常会启用"Auto Approve"等自动授权功能，从而绕过频繁的安全警告和权限请求。这种安全疲劳现象为混杂其中的恶意MCP服务器创造了成功利用漏洞的机会。
MCP聚合平台的责任真空
80%的参与者认为MCP聚合平台应该为安全负责，70%的参与者表明现有平台的专业外观可以提高其信任并降低对潜在安全风险的警惕。但我们的实验表明，这些提供商往往无法对新上架的MCP服务器进行全面的安全审核。此外，倘若恶意服务器实施了成功攻击，责任归属和划定就变得十分模糊。
大语言模型的信任悖论和固有防御局限
实验中，高攻击成功率（平均65.77%）与低LLMs拒绝率（低于23%）暴露了一个根本性的信任悖论：LLMs对工具描述和返回结果存在固有信任。问题产生在微调工具调用能力的SFT阶段，现有的工具调用示例数据缺乏抵抗恶意工具的对抗性样本，这使SFT后的LLMs虽然能够有效完成工具调用任务，但也难以检测工具描述中的恶意意图。
这项研究首次系统性揭露了MCP生态中潜藏的安全威胁——从恶意服务器渗透到聚合平台，到用户无意识地部署，再到大模型执行恶意操作，整个攻击链路已在实验环境中得到完整验证。
风险往往与机遇共生，安全问题的发现恰恰为构建更健壮的LLM生态系统提供了关键指引：通过建立严格的审核机制、部署智能安全网关、推行加密签名与可信分发标准、提升LLM基座模型的防御能力，在未来，我们完全有能力在开放与安全之间找到平衡点。
