Cursor IDE 0day 漏洞：打开恶意仓库即可自动执行任意代码

Aaron Portnoy

2026 年 7 月 14 日

更新于：

2026 年 6 月 17 日

似乎没人有兴趣修复的漏洞

要点总结

加载项目后，Cursor 会尝试在包括当前工作区在内的多个位置查找 git 二进制文件。只要在仓库根目录放置一个恶意的 git.exe，该 IDE 就会在没有任何用户交互、也不向用户发出任何提示的情况下执行它。这种情况会按一定频率反复发生。

有时安全研究揭示的是需要长篇解释的深度技术漏洞。这次并非如此。

这个 bug 很简单。开发者在 Windows 上用 Cursor 打开一个仓库，如果该仓库的项目根目录下包含一个恶意的 git.exe，Cursor 就会自动执行它。没有任何点击、提示、批准对话框或警告。其结果是任意代码执行。

鉴于 Cursor 是应用最广泛的 AI 辅助开发环境之一（活跃用户超过 700 万，日活超过 100 万，付费用户超过 100 万，被 5 万多家公司使用），且其报道的市场估值为 600 亿美元，按理说应当对安全实践存在一定程度的重视，但这个问题表明事实并非如此。

该漏洞最早由 Mindgard 于 2025 年 12 月 15 日发现。我们在当天即进行了报告，此后又多次报告。超过六个月、197 个以上新版本之后，该问题在最新测试的 Cursor 版本中依然存在。

该漏洞并非理论上的，也不依赖于复杂的利用链、提示词注入、模型操纵、越狱、内存破坏或高明的攻击者手法。利用它只需开发者打开一个在仓库根目录中包含 git.exe 二进制的项目即可。

‍

Cursor 用户现在该怎么做

企业/受管 Windows 系统： 作为受管 Windows 系统上的临时缓解措施，管理员可以使用 AppLocker 或 Windows App Control 策略，拒绝从开发者工作区目录执行受影响的可执行文件名。优先使用限定在仓库/工作区根目录的基于路径的拒绝规则，例如 %USERPROFILE%\source\repos\*\filename.exe，而不是基于哈希的规则，因为攻击者提供的二进制文件哈希可能各不相同。Windows 并未提供通用的内置规则来仅在特定父进程启动时阻止任意子可执行文件，因此感知父进程的强制执行通常需要 EDR 或自定义终端安全产品。

消费者系统： 在 IDE 被打补丁之前，仅在隔离的 VM、Windows Sandbox 或其他一次性环境中打开不受信任的仓库。不要依赖文件哈希阻止列表来应对此问题。

‍

对一个直白问题的奇怪回应

这次披露中最令人困惑的部分是 Cursor 方面没有任何回应。在七个月的时间里，Mindgard 反复尝试通过所有可用渠道进行联系。最初的披露按照该公司公开的 security.txt 文件中指定的方式，直接发送到了 Cursor 的安全报告电子邮箱。在未收到确认后，又发送了后续跟进。公开外联是为了尝试找到合适的安全联系人。

最终，Cursor 的首席信息安全官（CISO）作出了回应，承认一次内部自动化故障导致预期的 HackerOne 工作流未能执行。我们被邀请加入其私密漏洞赏金项目，并重新提交了报告。

该报告最初被以“信息性”且超出范围为由关闭。在我们对该判定提出异议后，HackerOne 重新打开了报告，复现了该问题，并确认相关细节已送达 Cursor。然后一切就停滞了。请求更新无人回应，后续追加跟进也杳无音信，通过 HackerOne 升级也未产生任何有意义的互动，直接联系 Cursor 领导层也得到了同样的结果：没有回应。

一个月又一个月过去了，没有任何证据表明修复工作已经开始、工程团队正在积极调查该问题，或者受影响的用户会被告知相关风险。与此同时，Cursor 继续发布新版本。随着功能不断上线、公告持续发布、平台不断演进，70 多个版本来了又走。但该漏洞依然存在，反复请求状态更新也未得到任何有意义的回应。

在某个时刻，讨论会从漏洞披露转向一个更令人不安的问题：安全流程究竟是为了什么？

‍

这个 Bug

技术问题本身其实非常简单直接。在加载项目时，Cursor 会尝试在多个位置查找 Git 二进制文件。其中一个位置就包括工作区本身。

如果攻击者在仓库根目录放置了一个恶意的 git.exe，Cursor 会在其路径解析逻辑中自动执行它，既没有警告，也没有征得批准，甚至没有任何迹象表明仓库中的可执行内容即将运行。

为了安全地演示该问题，Mindgard 使用了一个无害的概念验证：将 Windows 计算器应用程序重命名为 git.exe，放置在仓库根目录中。仅仅用 Cursor 打开该仓库就足以执行它。

下面的截图展示了结果。那些多个计算器窗口并非研究人员手动打开的。在项目保持打开状态期间，Cursor 持续重新执行这个被重命名的二进制文件，导致随着时间推移出现越来越多的实例。换句话说，这不是一次性的启动事件，也不是用户触发的操作。Cursor 在正常操作过程中反复调用了工作区内部的可执行内容。

‍

*一个无害的概念验证：将 Windows 计算器重命名为 git.exe。在项目打开后，Cursor 反复从仓库根目录执行该二进制文件。*

‍

在真实的攻击场景中，计算器只需被替换为攻击者控制的代码即可。

其结果是，在当前用户权限下可执行任意代码，如下方的 Sysinternals 进程监视器日志所示（最后验证于 2026 年 4 月 30 日，针对 Windows 上的 Cursor 3.2.16 版本）。

‍

4:25:12.6209706 PM	Cursor.exe	54880	Process Create	c:\Users\aport\Documents\Audits\cursor\test_repos\git_exec0001\git.exe	SUCCESS	PID: 48972, Command line: git rev-parse --show-toplevel	"C:\Users\aport\AppData\Local\Programs\cursor\Cursor.exe" 	C:\Users\aport\AppData\Local\Programs\cursor\Cursor.exe

‍

这个漏洞简单到几乎令人乏味，而这或许正是最令人担忧的地方。在正常运行过程中，Cursor 会执行来自某个仓库的、由攻击者控制的二进制文件，且无需任何用户交互。这样一个直白的问题竟能持续数月而未被修复，这应当让每一个正在部署 Cursor 的个人和组织感到担忧。

‍

为什么这次披露与众不同

大多数协同披露都遵循一个熟悉的模式：

有人报告了一个漏洞。
对话就此展开。
讨论其严重程度。
工程团队展开调查。
开发修复方案。
用户得到保护。
随后进行公开披露。

这一流程之所以有效，是因为各方都拥有一个共同目标：降低风险。

遗憾的是，此案例从未进入风险降低阶段。七个月过去，厂商始终未参与沟通，是时候质疑：针对这样一个简单却影响重大的漏洞，修复究竟是否还会发生。

安全研究人员理解修复需要时间，尤其是在庞大且快速演进的软件平台内部。然而，当数月过去却没有任何沟通、更新或可见进展时，耐心便难以再被合理化。用户理应获得针对基本威胁的基本防护，而当厂商一边停止沟通、一边继续分发受影响的软件时，研究人员最终将面临一个令人不安的抉择：

保持沉默，让用户在虚假的安全假设下继续使用。
或者，公开披露该问题，以便各组织能够做出知情的风险决策。

我们认为用户理应获得这些信息。完全披露是漏洞披露中的核选项，仅保留给所有其他途径都已失败的情况。它的存在是有原因的：当厂商停止沟通时，用户不应被蒙在鼓里。

‍

当创新不再倾听，会发生什么？

最显而易见的问题也最简单：为什么这个问题还没有被修复？

这个漏洞既不隐蔽，也不难以复现，执行路径直接，影响却极为严重。Cursor 敷衍的回应引出了更广泛的疑问：

现代漏洞赏金计划是否正在不堪重负？
漏洞赏金计划是否因为 Mythos 等能力越来越强的模型而不堪重负？
Cursor 是否因忙于收购 SpaceX 而将用户安全降为次要优先级？
当数十亿美元利益攸关时，用户安全还会被放在心上吗？

安全行业多年来一直鼓励研究人员使用协调披露渠道。这些渠道依赖于响应及时的分诊流程，以及厂商具备评估和处理所收到报告的能力。然而随着 AI 产品激增，安全发现的数量正在急剧上升。其中许多发现是新颖的，无法整齐地归入传统的漏洞类别。与此同时，我们依赖了近二十年的分诊流程正在迅速失效，因为它们所基于的核心假设在 AI 这一新兴世界中正逐渐崩塌。

如果披露管道正在不堪重负，行业应当如实说明。研究人员、客户和用户理应获得透明度。

遗憾的是，随着优先级这一令人不安的问题日益凸显，情况可能并非如此。与许多其他公司一样，Cursor 一直处于巨大增长、投资和行业关注的中心。该公司正在快速扩张，但从外部来看，很难将这种增长与一个直截了当的任意代码执行漏洞上迟迟看不到进展这一事实调和起来。

快速增长带来了一种责任：既要解决安全漏洞，也要将用户视为有价值的客户，而非购买实验品。他们信任生产软件，赋予其访问源代码、凭证、专有知识产权以及越来越多自主能力的权限。

信任需要问责，而问责需要沟通。当用户、研究人员和披露平台花费数月寻求基本的进展更新却无果时，这种问责就变得难以看见或令人信服。

‍

更大的问题

这一披露所涉及的，远不止一个名为 git.exe 的可执行文件，而是软件中的信任问题。AI 公司惯常要求用户授予前所未有的访问权限，涵盖代码、代码仓库、终端、密钥以及工作流，而这些权限正日益模糊建议与行动之间的界限。

行业叙事宣称这些系统值得信任，因为它们提升了生产力，但历史一再告诉我们，信任不应因为某样东西有用就被授予。信任应当通过行为来赢得。这种行为体现在一家公司如何回应安全报告、如何与受影响的用户沟通，以及如何优先安排修复工作。

当显而易见的漏洞数月得不到解决、也没有实质性沟通时，用户就不得不重新审视关于这种信任的种种假设。

‍

为什么我们要全面披露

与许多安全研究团队一样，Mindgard 倾向于协调披露。目标始终是安全第一，公开第二。

但协调披露只有在存在协调时才有效。在初次披露七个月后，我们没有任何迹象表明用户正在受到保护、修复工作正在进行，或者受影响的组织已被告知。而到了这个阶段，继续隐瞒信息已不再服务于用户，而是在服务于沉默。

出于这一原因，Mindgard 正在公布该漏洞的完整细节。使用 Cursor 的组织理应有机会评估自身暴露风险、实施补偿性控制措施，并就其安全态势做出知情决策。

用户安全必须放在首位，即便披露变得令人不适。

尤其是在披露变得令人不适的时候。

‍

时间线

日期	操作
2025 年 12 月 15 日	漏洞由 Mindgard 发现
2025 年 12 月 15 日	漏洞已报告至 security-reports@cursor.com
2025 年 12 月 18 日	跟进邮件，请求确认收到
2026 年 1 月 13 日	Mindgard 在 LinkedIn 上发帖，请求 Cursor 提供一位联系人以协助处理。有用户在评论中提到了 Cursor 的 CISO。
2026 年 1 月 15 日	Cursor 的 CISO 回复了该邮件线程，表示一个本应邀请加入 HackerOne 私有漏洞赏金计划的自动化流程失败了。CISO 手动邀请 Mindgard 加入该赏金计划。
2026 年 1 月 15 日	通过 HackerOne 提交漏洞
2026 年 1 月 16 日	报告最初被关闭，理由为信息性且超出范围
2026 年 1 月 16 日	Mindgard 对该判定提出异议
2026 年 1 月 16 日	在成功复现后报告被重新打开
2026 年 1 月 20 日	HackerOne 确认已交付给 Cursor
2026 年 2 月 16 日	已请求更新，未收到回复
2026 年 3 月 3 日	已请求更新，未收到回复
2026 年 3 月 17 日	直接联系 Cursor CISO 请求更新
2026 年 3 月 18 日	HackerOne 表示已联系 Cursor
2026 年 4 月 1 日	已请求更新，未收到回复
2026 年 4 月 1 日	HackerOne 确认 Cursor 未提供更新
2026 年 6 月 1 日	Mindgard 通知 HackerOne 其有意公开披露
2026 年 6 月 3 日	HackerOne 提供披露指导
2026 年 7 月 14 日	本博客文章发布。

开始保护你的 AI 系统

了解 Mindgard 如何揭示并修复你的 AI 智能体和系统中可被利用的 AI 风险。

预约演示

Mindgard 是领先的 AI 安全解决方案提供商，帮助企业发现、评估并防御其 AI 系统。Mindgard 脱胎于兰卡斯特大学十余年的 AI 安全研究，总部位于波士顿和伦敦，将 AI 红队测试与攻防安全专业知识和 AI 研究相结合，在攻击者之前识别出 AI 模型、智能体和应用中可被利用的漏洞。

AICPA SOC SOC 2 Type 2 Compliant

平台

平台概览

AI 发现与侦察

AI 红队测试

AI 评估

AI 运行时防护

攻防安全

模型扫描

AI 治理与合规

AI 学院

应用场景

服务

服务概览

AI 安全对比

公司

关于

预约演示

活动

招聘

联系我们

条款与条件