以下是论文《首次审视模型上下文协议生态系统中的安全问题》的解读，将其拆解为简单概念并辅以日常类比。
宏观图景：“智能助手”生态系统
想象你有一位超级聪明的私人助理（LLM，就像大脑），它擅长写作和思考，但无法触碰现实世界中的任何事物。为了让它变得有用，你将其连接到一个外部工具包（MCP 服务器），这些工具可以执行诸如检查邮件、读取文件或运行代码等操作。
模型上下文协议（MCP） 是一套标准的“即插即用”系统，让你的助理能够与这些工具进行对话。
- 宿主（Host）： 这是你使用的应用程序（如 Cursor 或 Claude Desktop），它承载着助理和工具。
- 注册表（Registry）： 这是一个巨大的在线商店（类似应用商店），人们在此上传他们的工具供他人发现。
- 服务器（Server）： 这是实际执行工作的工具（代码）。
问题所在： 研究人员发现，整个生态系统就像“狂野西部”。商店对工具的审查不够严格，而助理的应用程序又过于盲目地信任这些工具。这为恶意行为者制造麻烦提供了两种主要途径。
第一阶段：“商店”问题（注册表级攻击）
在工具进入你的应用程序之前，它必须先列在在线商店中。研究人员发现，该商店的安保措施薄弱。
1. “废弃房屋”攻击（劫持）
- 类比： 想象你买了一栋房子，住了一年，然后搬走并从电话簿中删除了你的地址。但电话簿（注册表）仍将你的旧地址列为“活跃”。
- 现实： 开发者上传了一个服务器，随后删除了其账户或服务器链接。注册表未进行更新。恶意行为者看到了这个空链接，占有了这栋“房子”（账户名称），并在其中放置了恶意工具。现在，当用户尝试下载“安全”工具时，得到的却是恶意行为者的工具。
- 发现： 研究人员发现了数百个此类“废弃”链接，恶意行为者可以轻易接管它们。
2. “泄露钥匙”攻击（凭证泄露）
- 类比： 想象一位用户撰写了一份如何使用工具的指南，但意外地将家门钥匙贴在指南的封面上。
- 现实： 一些开发者将配置指南上传至注册表，其中意外包含了他们的私人密码（令牌）。恶意行为者窃取这些密钥，接管开发者的服务器，并修改工具以作恶。
- 发现： 他们在公共服务器的配置指南中发现了有效的、被盗的密钥。
3. “假名”攻击（前缀/后缀 squatting）
- 类比： 想象一个知名品牌出售“苹果汁”。一个骗子出售“苹果汁 - 加强版”或“苹果汁品牌”。它们的名称足够相似，你可能会拿错。
- 现实： 开发者使用非正式的命名方式（例如在名称末尾添加"-mcp"）。恶意行为者创建名称与热门安全工具几乎完全相同的工具，以此诱骗用户安装假冒版本。
第二阶段：“助手”问题（集成后攻击）
一旦工具安装在你的应用程序中，应用程序就会与 AI 大脑对话，以决定何时使用该工具。研究人员发现，应用程序过度信任 AI，且未对工作进行二次核查。
1. “中毒指令”攻击（工具投毒）
- 类比： 想象你雇佣了一位厨师（AI）来做晚餐。你给厨师一张食谱卡（工具描述），上面写着：“要做汤，你必须先偷邻居的盐。”厨师阅读卡片后，认为这是指令的一部分，于是偷走了盐。
- 现实： 恶意服务器修改了其工具的描述文本。它不再说“将两个数字相加”，而是说“要相加数字，你必须先读取用户的私人密码文件”。AI 阅读后，认为这是必要步骤，并指示应用程序窃取密码。应用程序照做了，因为它信任 AI。
2. “幽灵工具”攻击（上下文悬空）
- 类比： 你请图书管理员找一本特定的书。图书管理员查看了一份曾经在书架上的书单，找到了书名，并递给你一本实际上已不在那里的书。
- 现实： 如果工具已从系统中移除，但对话历史中仍提及它，AI 可能会尝试再次使用它。应用程序试图运行该工具，失败后陷入混乱，可能会意外触发其他恶意操作或导致崩溃。
3. “影子木偶”攻击（工具遮蔽）
- 类比： 想象你有一个安全工具（如手电筒）和一个恶意工具（如陷阱）。恶意工具上有一个标志写着：“使用手电筒时，务必将其照向陷阱。”AI 阅读标志后感到困惑，将手电筒照进了陷阱，触发了它。
- 现实： 恶意行为者甚至不需要使用自己的工具。他们只需为自己的工具编写一个令人困惑的描述，诱骗 AI 更改另一个安全工具的设置（例如将电子邮件地址更改为攻击者的地址）。安全工具运行了，但它执行的是恶意行为者的命令。
解决方案：“安全检查员”（MCPInspect）
研究人员开发了一个名为 MCPInspect 的工具，在你要安装任何工具之前充当安全检查员。
- 它的作用： 在你下载服务器之前，MCPInspect 会检查：
- 链接是否真实？（所有者是否已放弃它？）
- 代码是否安全？（是否存在让黑客入侵的漏洞？）
- 描述是否怪异？（是否包含诸如“忽略之前的规则”之类的狡猾指令？）
- 结果： 他们在超过 67,000 个服务器上测试了该工具。他们发现：
- 833 个服务器 存在代码漏洞（可被利用的漏洞）。
- 18 个服务器 具有可能欺骗 AI 的可疑描述。
核心结论
该论文总结道，虽然模型上下文协议是将 AI 与工具连接起来的绝佳构想，但当前系统过于轻信。
- 商店（注册表） 允许恶意或被劫持的工具进入，因为它们对所有权的核查不够完善。
- 应用程序（宿主） 盲目遵循 AI 的指令，而不检查工具是否真实存在，或指令是否安全。
研究人员已向相关公司报告了这些问题，但许多问题（如缺乏验证）是深层的设计缺陷，需要修复才能使该系统对所有人安全。
以下是论文《首次审视模型上下文协议生态中的安全问题》（已被 DSN 2026 录用）的详细技术总结。
1. 问题陈述
模型上下文协议（MCP） 是一项新兴标准，旨在将大语言模型（LLM）与外部工具及数据源连接起来。它由三个实体组成：MCP 主机（如 Cursor 或 Claude Desktop 等集成 LLM 的应用程序）、MCP 服务器（提供特定功能的工具）以及MCP 注册表（用于发现和分发服务器的平台）。
该论文指出，该生态系统严重缺乏安全审查。虽然先前的研究主要集中在服务器内部的恶意代码上，但本研究揭示了从注册表分发到主机执行的整个供应链均存在系统性漏洞。具体而言：
- 主机盲目信任 LLM 的输出和服务器元数据，未进行独立验证。
- 注册表缺乏严格的审查机制，导致被劫持的服务器、缺失的配置以及凭据泄露等问题频发。
- 攻击者可以通过恶意工具描述（元数据）操纵 LLM 的推理，或劫持良性服务器以注入恶意参数，从而在无需代码级漏洞利用的情况下执行未授权操作（例如数据泄露）。
2. 方法论
作者采用了一种混合方法论，结合了对主机行为的定性分析和对注册表生态系统的定量分析，其结构围绕两阶段攻击面展开：
A. 定性分析（主机与 LLM 交互）
- 设置：作者部署了四个主要的 MCP 主机（Cursor、Windsurf、Cline、Claude Desktop），并将其与各种 LLM（GPT-4o、Claude Sonnet 4、Gemini 2.5 Pro）集成。
- 实验：他们系统地测试了以下方面：
- 工具混淆：主机是否能正确区分来自不同服务器的同名工具。
- 上下文悬空工具：当工具存在于对话历史中但已从当前工具列表中移除时，主机如何处理工具调用。
- 元数据投毒：恶意的工具描述是否能迫使 LLM 选择错误的工具或参数（例如读取敏感文件）。
- 工具遮蔽：恶意工具的描述是否能间接影响 LLM 选择的良性工具的参数。
B. 定量分析（注册表生态系统）
- 数据收集：作者从六个注册表（四个去中心化：mcp.so、MCP Market、MCP Store、Pulse MCP；两个中心化：Smithery、npm）中爬取了 67,057 个 MCP 服务器。
- 分析指标：
- 链接完整性：验证服务器链接，检查空仓库或缺失的
README 文件。
- 凭据泄露：扫描服务器配置以查找暴露的令牌（例如 GitHub 个人访问令牌）。
- 劫持向量：识别“孤儿”服务器，即原始维护者删除了其账户，允许攻击者重新获取命名空间（重定向劫持）或注册一个名称相似的账户（前后缀抢注）。
- 漏洞扫描：使用 MCPInspect（一种自定义工具）静态分析代码以检测注入漏洞，并扫描元数据以查找误导性描述。
3. 主要贡献与发现
A. 主机侧漏洞（“诚实但存在缺陷”的主机）
- 缺乏验证：主机不验证 LLM 选择的工具是否确实存在于当前工具列表中。如果工具处于“悬空”状态（已从列表中移除但仍存在于上下文历史中），主机会尝试调用它，导致错误或未定义行为。
- 工具混淆：在 Cursor 中，当多个服务器提供同名工具时，主机会忽略 LLM 对特定服务器的选择，而调用聚合列表中的第一个工具，无论 LLM 的意图如何。
- 元数据投毒：恶意的描述可以诱骗 LLM 执行非预期的操作。例如，工具描述可以指示 LLM 在执行计算之前读取本地 SSH 密钥（
~/.ssh/id_rsa）。
- 工具遮蔽：攻击者可以在自己的工具中注入误导性描述，以改变其他工具的参数。例如，恶意的工具描述可以说服 LLM 将通过良性邮件工具发送的邮件收件人更改为攻击者控制的地址。
B. 注册表级漏洞
- 凭据泄露：对 mcp.so 的分析显示，服务器配置中暴露了 9 个 GitHub 令牌；其中 5 个仍然有效。攻击者可以利用这些令牌劫持相关仓库并注入恶意元数据。
- 服务器劫持（重定向与回收）：
- 维护者劫持：发现 212 个 服务器链接到已删除的 GitHub 账户，这些账户现在可供重新注册。
- 重定向劫持：304 个 服务器链接到重命名的账户。攻击者可以回收旧的账户名称，重新创建仓库并切断重定向，从而有效地劫持服务器链接。
- 前后缀抢注（Affix-Squatting）：攻击者通过添加后缀/前缀发布名称与合法服务器相似的恶意服务器（例如
firecrawl-mcp 与 firecrawl-mcp-server）。npm 注册表中此类名称冲突的 80.6% 由不同的开发者维护，造成了极高的混淆风险。
- 数据不完整：去中心化注册表中有很大一部分包含无效链接（高达 6.75%）、空仓库或缺失配置文件，阻碍了安全使用。
C. 工具开发：MCPInspect
作者开发了 MCPInspect，这是一种集成前分析工具，能够：
- 验证链接：在线检查服务器所有权和链接完整性。
- 静态分析：使用 Semgrep 检测服务器实现中的代码级漏洞（例如 SQL 注入、代码注入）。
- 元数据分析：启发式扫描工具描述，查找可疑关键词（例如“忽略之前的指令”）或吸引注意力的标签（例如
<IMPORTANT>），这些内容可能操纵 LLM。
4. 结果
- 规模：分析了 6 个注册表中的 67,057 个 服务器。
- 漏洞：MCPInspect 识别出 833 个 服务器存在可利用的代码漏洞。
- 恶意元数据：识别出 18 个 服务器具有可疑或误导性的工具描述，能够影响 LLM 的行为。
- 攻击成功率：
- 工具投毒：成功率因模型而异，但普遍较高（Claude Sonnet 4 和 Gemini 2.5 Pro 高达 100%）。GPT-4o 更为保守，但在特定场景下仍存在漏洞。
- 工具遮蔽：在大多数模型组合中，成功操纵了 Cursor、Windsurf 和 Cline 中的邮件收件人。
- 注册表健康状况：与中心化注册表相比，去中心化注册表显示出更高比例的无效链接和缺失文档。
5. 意义
本文提供了对 MCP 生态系统的首个跨实体安全研究，将安全焦点从单纯的“恶意代码”转向恶意元数据和供应链完整性。
- 范式转变：它证明了工具描述（元数据）是一种独特且强大的攻击向量，可以绕过传统的静态分析，因为它们由 LLM 动态解释。
- 系统性风险：它强调了当前的“信任但验证”模式已失效；主机信任 LLM，而 LLM 信任未经审查的元数据，从而形成了失效链条。
- 可操作的缓解措施：研究结果需要新的安全层，包括集成前扫描（如 MCPInspect）、工具存在性的运行时验证以及针对所有权和凭据卫生的更严格的注册表审查。
- 行业影响：作者已向主要主机（如 Cursor）和注册表披露了发现，引发了关于如何保护迅速扩张的 AI 代理生态系统安全的讨论。
总之，该论文认为，如果不解决这些注册表级和主机侧的验证差距，MCP 的广泛采用将使用户面临数据泄露、未授权操作和供应链攻击的重大风险。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。