Cursor IDE 任意代码执行漏洞

通过恶意 Git 二进制文件实现任意代码执行

Cursor IDE 存在一个漏洞，允许在 Windows 系统上无需用户交互即可实现任意代码执行 (ACE)。当 Cursor 加载项目时，其路径解析逻辑会在多个位置搜索 Git 二进制文件，包括当前工作区根目录。如果攻击者在仓库根目录下放置一个名为 git.exe 的恶意可执行文件，Cursor 将在正常运行期间自动执行它。

此漏洞并非一次性事件；只要项目保持打开状态，Cursor 就会以一定的频率重复调用该二进制文件，这使得攻击者能够维持持久性或在没有任何提示、确认对话框或警告的情况下多次执行命令。

技术根本原因与概念验证

该漏洞源于 Cursor 的 Git 二进制文件查找过程。IDE 尝试定位 git 命令以执行版本控制操作。由于其搜索路径中包含了工作区目录，它会优先于系统范围内的 Git 安装程序使用本地的 git.exe。

Mindgard 通过一个无害的概念验证演示了此漏洞：将 Windows 计算器应用程序重命名为 git.exe 并将其放置在仓库根目录中。在 Cursor 中打开该项目时，IDE 自动启动了多个计算器应用程序实例。Sysinternals Process Monitor 日志确认，Cursor.exe 通过命令行 git rev-parse --show-toplevel 发起了本地 git.exe 的进程创建。

缓解措施与保护策略

在 Cursor 发布正式补丁之前，用户和管理员应实施以下保护措施：

对于企业和受管 Windows 系统

管理员应使用 AppLocker 或 Windows App Control 策略来防止执行来自开发人员工作区目录的二进制文件。建议使用基于路径的拒绝规则，而非基于哈希的规则，以应对不断变化的攻击者二进制文件。建议的规则范围为：%USERPROFILE%\source\repos\*\filename.exe。

对于个人开发人员

避免在宿主机器上打开不受信任的仓库。相反，请使用隔离环境，例如：

• Windows Sandbox
• 隔离的虚拟机 (VMs)
• 可丢弃的开发容器

披露时间线与厂商响应

Mindgard 最初于 2025 年 12 月 15 日识别并报告了此漏洞。尽管在七个月内多次尝试协调修复，但在截至 2026 年 4 月 30 日测试的版本中（版本 3.2.16），该问题仍未得到修复。

根据披露时间线，报告过程遇到了多次失败：

• 初始报告： 于 2025 年 12 月 15 日通过官方 security.txt 电子邮件发送。
• 分诊： 在 LinkedIn 上进行公开接触后，Cursor CISO 承认 HackerOne 工作流中的自动化失败，并于 2026 年 1 月 15 日手动邀请研究人员加入漏洞赏金计划。
• 确认： HackerOne 重现了该问题，并于 2026 年 1 月 20 日确认交付给 Cursor。
• 沉默： 从 2026 年 2 月到 6 月，通过 HackerOne 和直接联系领导层的多次更新请求均未得到回应。

社区观点与反驳观点

在公开披露后，开发者社区就该漏洞的严重程度和性质提出了若干观点：

反对高严重性的观点

一些用户认为该漏洞并不那么关键，因为它要求攻击者已经拥有用户文件系统上的一个文件。一位评论者指出：

"一个攻击者必须将一个恶意的 .exe 文件命名为 git.exe 并放置在用户的代码文件夹中，才能发生这种情况... 如果他们已经那样把东西放在了你的文件系统中，那么你已经被攻破了。"

其他人建议，如果这些安全功能未被禁用，Windows Access Control Lists (ACLs) 或未签名应用程序的警告可能会减轻其影响。

支持高严重性的观点

其他贡献者指出，这是用户从公共来源克隆不受信任仓库时的常见向量。风险在于，一个旨在处理不受信任代码的 IDE——即一个处理工具——不应该在没有用户明确同意的情况下，自主地执行来自该代码内部的二进制文件，无论用户是否已在 IDE 的工作区信任对话框中点击了 "Trust this folder"。

系统性问题

讨论还涉及到了 AI 驱动开发工具更广泛的影响。一些人质疑为什么会存在这样的功能，并对快速增长和高估值的 AI 行业可能导致公司优先考虑基础安全卫生和响应式漏洞披露流程之外的其他事项，表示了担忧。