没有人似乎对修复的漏洞 关键要点 在加载项目后，Cursor尝试在多个位置查找git二进制文件，包括当前工作区。通过在根目录中创建一个植入恶意git.exe的存储库，IDE将自动执行它，无需用户交互或提示。这会反复发生，按一定节奏进行。有时，安全研究会揭示出需要数页解释的深度技术漏洞，但这并不是这种情况。这个漏洞很简单。开发者在Windows上的Cursor中打开一个存储库，如果该存储库在项目根目录中包含恶意git.exe，Cursor将自动执行它。没有点击、提示、批准对话框或警告。结果是任意代码执行。考虑到Cursor是最广泛采用的AI辅助开发环境之一（700万以上活跃用户，100万以上日活跃用户，100万以上付费用户，50,000多家公司使用），以及其报告的市场价格为600亿美元，可以合理地推测存在一定程度的安全实践尊重，但这个问题表明情况并非如此。该漏洞首次由Mindgard于2025年12月15日确定。我们在同一天报告了该漏洞，并多次跟进。六个月后，经过197多个新版本，最新测试版本的Cursor中仍然存在该问题。该漏洞不是理论上的，也不依赖于复杂的利用链、提示注入、模型操控、越狱、内存损坏或复杂的攻击者技术。利用只需开发者打开一个包含根目录中git.exe二进制文件的项目。 Cursor用户现在应做的事情 企业/管理的Windows系统：作为对管理Windows系统的临时缓解，管理员可以使用AppLocker或Windows应用控制策略拒绝执行受影响的可执行文件名称，限制开发者工作区目录中的应用程序。请优先考虑基于路径的拒绝规则，限制在存储库/工作区根目录，例如%USERPROFILE%\source\repos\*\filename.exe，而不是基于哈希的规则，因为攻击者提供的二进制文件可以在哈希上有所不同。Windows没有提供一般的内置规则来仅在由特定父进程启动时阻止任意子可执行文件，因此，亲代感知的强制执行通常需要EDR或自定义终端安全产品。 消费者系统：在IDE修补之前，仅在隔离的虚拟机、Windows沙箱或其他一次性环境中打开不受信任的存储库。请不要依赖文件哈希黑名单来解决此问题。 对简单问题的奇怪反应 此次披露中最令人困惑的部分是Cursor缺乏响应。在过去的七个月中，Mindgard多次尝试通过每一个可用渠道进行沟通。初次披露是直接发送到Cursor的安全报告电子邮件地址，正如公司在发布的security.txt文件中所规定的那样。当未收到确认时，进行了后续跟进。公众联系的方式旨在确定适当的安全联系人。最终，Cursor的首席信息安全官回应并承认，内部自动化故障阻止了预期的HackerOne工作流程。我们被邀请进入私有漏洞奖励程序并重新提交报告。该报告最初被关闭为信息性且不在范围内。在我们对这个认定提出质疑后，HackerOne重新开放了报告，重复了问题，并确认已将详细信息传递给Cursor。然后一切都停止了。更新请求没有得到回应，额外的后续没有回复，通过HackerOne的升级没有产生任何积极的互动，直接联系Cursor领导层也得到了相同的结果：没有回应。一个月又一个月的过去，没有证据表明补救工作已经开始，工程团队正在积极调查该问题，或受影响的用户将被告知风险。与此同时，Cursor继续推出版本。超过70个版本不断发布，功能上线，公告持续，而平台不断演变。然而，漏洞依然存在，重复请求状态更新没有得到任何有效的回应。在某个时候，讨论从漏洞披露转向了一个更不舒服的问题：安全流程究竟是为了什么？ 漏洞 技术问题本身相当简单。在加载项目时，Cursor会尝试在多个位置查找Git二进制文件，其中一个位置就是工作区本身。如果攻击者在存储库根目录中植入了一个恶意git.exe，Cursor将根据其路径解析逻辑自动执行该文件，而不会发出警告、获得批准或甚至表示将要运行来自存储库的可执行内容。为了安全地演示这个问题，Mindgard使用了一个无害的概念验证：Windows计算器应用程序。