第四层：当 MCP 攻击进入你的 IDE
I’m ready to translate the article for you, but I need the full text of the post (the content that follows the source line). Could you please paste the article’s body here? Once I have the text, I’ll provide a Simplified Chinese translation while preserving the original formatting, markdown syntax, and technical terms.
Overview
三周前，我发布了一篇关于 MCP 攻击面在三个层面的分析：servers、developer tooling 和 host applications。当时我们有 30 CVEs。
今天，Knostic.ai 发布了关于 CVE‑2026‑27180 的研究，这增加了 第四层——它是迄今为止最危险的一层。
Target
Cursor IDE – 一个被数百万开发者使用的 AI 驱动代码编辑器
Researcher: Dor Munis, Knostic.ai
Attack type:
MCP server → JavaScript 注入 → 凭证窃取 → 完全工作站妥协该攻击不需要代码执行或任何用户发起的工具调用。它在 Cursor 加载 MCP 服务器的工具列表的瞬间触发。
攻击流程
- 恶意 MCP 服务器 已安装（例如，来自 GitHub、Discord 或精选列表）。
- 当 Cursor 调用
tools/list以发现可用工具时，恶意服务器：- 钩入 Cursor 的内部扩展目录。
- 将
document.body.innerHTML = [attacker payload]注入 Cursor 的嵌入式浏览器。
- 在 Cursor 中打开的每个浏览器标签页现在都会显示攻击者控制的内容，而地址栏仍显示合法的 URL。
- 开发者在看似自己应用的登录页面中输入凭据。
结果链路：
MCP discovery → IDE modification → browser hijack → credential theft无需执行任何工具；被动握手已足够。
为什么 Cursor 易受攻击
- Cursor 是 VS Code 的一个分支，内置 AI 功能。
- VS Code 会对其扩展文件执行完整性检查；Cursor 则没有。
- 因此，对 Cursor 内部代码的任何修改——无论是来自 MCP 服务器、扩展，还是任何具有文件系统访问权限的进程——都会悄无声息地进行，不会出现警告或校验和失败。
Knostic 研究人员将此漏洞描述为 “在一次 eval 上再套一次 eval”：注入的代码在 Cursor 浏览器上下文中运行，而该上下文本身是一个评估环境，拥有对用户开发状态的完整访问权限。
“MCP 服务器在安全性方面应当被视为与 VS Code 扩展完全相同。” – Dor Munis 对 CSO 的说法
Source: …
现有框架（三层）
| 层 | 示例 | CVE 数量 |
|---|---|---|
| L1: MCP 服务器 | exec() 注入、eval() 绕过、路径遍历 | 25 |
| L2: 开发者工具 | MCP Watch、MCPJam Inspector、MCP Probe | 3 |
| L3: MCP 主机应用 | Dive deeplink、Dive XSS/Mermaid | 2 |
新的第四层 (L4)
| 层 | 描述 | CVEs |
|---|---|---|
| L4: MCP 客户端/IDE | Cursor 浏览器注入 | 1（且在增加） |
L4 与 L3 有何不同？
| 方面 | L3 – 主机应用（例如 Dive） | L4 – IDE 客户端（例如 Cursor） |
|---|---|---|
| 角色 | 运行 MCP 服务器并管理连接（编排层）。 | 开发者构建应用的地方；拥有提升的权限（文件系统访问、进程执行、开发者凭证、签名密钥）。 |
| 信任 | 开发者与远程服务交互。 | 开发者将 IDE 视为自己的工具，而非第三方服务器。 |
| 妥协影响 | 可能影响单个服务或工作流。 | 让攻击者获得开发者使用的所有服务、所有推送的仓库以及开发期间存储的所有机密。 |
tools/list 侦察问题 — 重访
- 在我们之前对 AWS EC2 爬虫行为的分析中，70 % 的 MCP 协议流量是
initialize → tools/list → disconnect，且 没有任何工具调用。我们将其解释为攻击者仅在映射攻击面。 - CVE‑2026‑27180 显示了相反的情况：服务器 可以将
tools/list用作 钩子——不仅仅是客户端用于侦察。
关键洞察：
tools/list并非被动。当 MCP 客户端调用它时，会建立 信任关系，且响应可以 修改客户端环境。
此表面同样被用于：
- 工具投毒攻击（恶意工具描述，用于操纵 LLM 行为）
- 通过工具元数据进行提示注入
因此，攻击面是 工具发现，而非工具执行。
完整 CVE 概览（截至今日）
| 层 | 子类别 | CVE数量 | 常见问题 |
|---|---|---|---|
| L1 – 服务器 | exec() 类 | 10 | child_process.exec() 未经消毒 |
eval() 类 | 3 | Python eval 有/无作用域限制 | |
| 其他服务器 | 12 | 路径遍历、认证绕过、凭证泄露、SSRF | |
| L2 – 开发者工具 | — | 3 | 安全扫描器、调试器、检查器 |
| L3 – 宿主应用 | — | 3 | Dive（两种向量）、eBay 环境注入 |
| L4 – IDE/客户端 | — | 1 | Cursor 浏览器注入 |
模式： 整个生态系统主要将 MCP 安全视为服务器端问题。除 L1 之外的每一层都是在研究人员专门寻找后才被发现的——而不是由构建这些工具的开发者发现的。
立即行动
- 审计您已安装的所有 MCP 服务器。
cat ~/.cursor/mcp.json # 或系统上等效的路径 - 对每个服务器：
- 找到其 GitHub 仓库。
- 审查源代码。
- 记住：MCP 服务器以 您 IDE 的权限 运行——等同于根权限。
- 禁用 YOLO/自动运行模式。
- 当代理在没有人工确认的情况下执行操作时，工具发现与任意执行之间没有检查点。
- 避免从 Discord、Reddit 或聚合列表中安装 MCP 服务器，除非进行代码审查。
- 即使是精选列表也不完美；我们的数据集显示官方 MCP 注册表存在质量问题。
- 对请求 与其声明目的无关的广泛文件系统或网络访问 的 MCP 服务器保持怀疑。
推荐的 Cursor 缓解措施
| 缓解措施 | 理由 |
|---|---|
| 对扩展文件进行完整性检查（如 VS Code 所做） | 检测 IDE 内部代码的未授权修改。 |
| 对嵌入式浏览器进行沙箱隔离（独立进程、受限权限） | 防止注入的脚本访问完整的开发环境。 |
| 对 MCP 服务器包进行代码签名（类似浏览器扩展签名） | 确保来源可信并防止篡改。 |
| 容器隔离（例如 Docker） | 限制受损 IDE 的影响，尽管 CVE‑2026‑27180 在任何容器启动 之前 就已发生。 |
Docker 最近的 “MCP Horror Stories” 系列强调了防御性工具和容器化作为缓解措施。虽然容器隔离有帮助，CVE‑2026‑27180 在宿主环境中执行，因此上述 IDE 级别的防御至关重要。
已清理的 markdown 结束。
rts.
攻击面扩展的速度快于任何单一防御框架能够应对的速度。容器隔离可以保护服务器，但它并不能保护加载服务器工具列表的 IDE。
MCP 的正确安全模型不是 “在容器中运行服务器”。 而是 “将每个 MCP 服务器视为在你的开发环境中执行的敌对二进制文件”。
这不是技术问题——而是文化问题。而 六周内出现 33 个 CVE 表明文化尚未跟上。
资源
- 实时 MCP 扫描器和 CVE 注册表：
- 完整的 33‑CVE 数据集：
mcp-disclosures.md - 上一篇文章： Two New CVEs — eval() bypass + Dive XSS