光标 0day:当完全披露成为唯一的保护时
原文链接:https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left
Cursor 0day:当完全披露成为唯一的保护时 - Mindgard Services Learn 公司演示 演示 Cursor 0day:当完全披露成为唯一的保护时 Aaron Portnoy 2026 年 7 月 14 日更新:2026 年 6 月 17 日 该漏洞似乎没有人对修复感兴趣 关键要点 加载项目后,Cursor 尝试在包括当前工作区在内的各个位置查找 git 二进制文件。通过在根目录中创建一个植入了恶意 git.exe 的存储库,IDE 将在没有用户交互和用户提示的情况下执行它。这种情况按节奏重复发生。有时,安全研究会发现需要大量解释的深层技术漏洞。这不是其中之一。这个错误很简单。开发人员在Windows上的Cursor中打开一个存储库,如果该存储库在项目根目录中包含恶意git.exe,Cursor将自动执行它。没有点击、提示、批准对话框或警告。结果是任意代码执行。鉴于 Cursor 是最广泛采用的人工智能辅助开发环境之一(超过 700 万活跃用户、超过 100 万每日用户、超过 100 万付费用户、超过 5 万家公司使用),并且其报告的市场价格为 600 亿美元,可以公平地假设存在一定程度的对安全实践的尊重,但这个问题表明情况并非如此。
Mindgard 于 2025 年 12 月 15 日首次发现该漏洞。我们在同一天报告了该漏洞,此后多次报告。六个多月和 197 多个新版本过去后,该问题仍然存在于最新测试的 Cursor 版本中。该漏洞不是理论上的,也不依赖于复杂的利用链、提示注入、模型操纵、越狱、内存损坏或复杂的攻击者交易技术。利用该漏洞只需要开发人员在根目录下的存储库中打开一个包含 git.exe 二进制文件的项目。光标用户现在应该做什么企业/托管 Windows 系统:作为托管 Windows 系统的临时缓解措施,管理员可以使用 AppLocker 或 Windows 应用程序控制策略来拒绝执行开发人员工作区目录中受影响的可执行文件名称。首选基于路径的拒绝规则,范围仅限于存储库/工作空间根目录,例如 %USERPROFILE%\source\repos\*\filename.exe ,而不是基于哈希的规则,因为攻击者提供的二进制文件可能会因哈希而异。
Windows 不提供通用的内置规则来仅在由特定父进程启动时阻止任意子可执行文件,因此父级感知强制执行通常需要 EDR 或自定义端点安全产品。消费者系统:在 IDE 修补之前,仅在隔离的 VM、Windows Sandbox 或其他一次性环境中打开不受信任的存储库。不要依赖文件哈希阻止列表来解决此问题。对简单问题的奇怪响应 本公开中最令人困惑的部分是 Cursor 没有响应。在七个月的时间里,Mindgard 反复尝试通过所有可用的渠道进行参与。最初披露的信息直接发送到 Cursor 的安全报告电子邮件地址,如该公司发布的 security.txt 文件中指定的那样。在未收到确认的情况下发送了后续信息。我们进行了公开宣传,试图确定适当的安全联系人。最终,Cursor 的 CISO 做出回应并承认内部自动化故障导致预期的 HackerOne 工作流程无法进行。我们被邀请参加私人错误赏金计划并重新提交了报告。该报告最初被视为信息性且超出范围而关闭。在我们对这一决定提出质疑后,HackerOne 重新打开了报告,重现了该问题,并确认详细信息已发送给 Cursor。进而