Cursor IDE 0day 漏洞允许通过打开恶意仓库执行任意代码

Cursor IDE 包含一个零日漏洞，攻击者只需诱骗用户在 Windows 上打开恶意仓库即可执行任意代码。一旦文件夹加载，无需点击或明确批准即可完成。

安全公司 Mindgard 于 2025 年 12 月 15 日发现该问题。该漏洞源于 Cursor 在多个文件夹（包括工作区本身）中搜索 Git 二进制文件的方式。

漏洞如何实现无交互代码执行

当项目打开时，Cursor 会在多个位置查找 git.exe。其中一个位置是当前工作区文件夹。攻击者可以在仓库中放置一个名为 git.exe 的恶意文件。

当用户克隆或打开该文件夹时，Cursor 会自动运行攻击者文件。由于搜索顺序将工作区位置置于 Windows 更安全的系统路径之前，因此会触发执行。

在仓库首次加载后，攻击无需任何进一步用户操作。研究人员在当前 Windows 版本上测试了该向量，并确认执行一致。

时间线显示多次报告但修复缓慢

Mindgard 在七个月内多次联系 Cursor。公司 CISO 确认了报告，但内部自动化故障导致问题未进入工程队列。

在此期间发布了七十多个新版本。均未解决搜索顺序问题或添加 Git 二进制文件验证。

Cursor 至今仍未发布修复版本。由于内部修复无进展，漏洞已转为完全公开披露。

用户可立即采取的实用措施

AppLocker 规则可阻止从工作区目录执行任何名为 git.exe 的文件。即使 Cursor 尝试调用，该策略也能防止恶意二进制文件运行。

在隔离的虚拟机中运行不受信任的仓库也能限制暴露。如果代码启动，虚拟机可保护宿主系统安全。

macOS 上的 Cursor 用户面临的风险较低，因为搜索路径行为与 Windows 不同。当工作区路径在二进制文件查找中优先时，Linux 版本显示出类似暴露。

为什么 IDE 搜索逻辑会持续带来风险

许多编辑器依赖系统环境变量来定位 Git 等工具。Cursor 将该逻辑扩展到项目文件夹以提升速度。当仓库来自未知来源时，这种额外灵活性会扩大攻击面。

其他自动检测二进制文件的开发工具中也出现过类似模式。每种情况都需要显式允许列表或哈希检查才能降低风险。

Cursor 尚未发布公开声明，说明新安全措施或计划发布日期。该供应商继续发布更新，但保留原始查找顺序不变。

披露后仍不明确的问题

Mindgard 尚未发布完整的概念验证或利用链。通过相同搜索可能发现的其他二进制文件的具体范围仍未知。

目前仍不清楚该公司是否计划限制工作区二进制文件查找，或仅依赖用户端策略。尚未宣布与其他 IDE 供应商的协调披露时间表。

打开来自未知贡献者的仓库的开发者应立即应用缓解步骤。该问题表明，当搜索路径未经验证时，IDE 中的便利功能可能会破坏标准操作系统保护。