在安全研究领域，部分技术漏洞需要长篇大论才能阐释清楚，但眼前的这个漏洞并非如此。
这个漏洞的核心机制其实相当直观。当开发者在Windows系统上使用Cursor并打开一个项目仓库时，若该仓库根目录下隐藏了一个恶意git.exe文件，Cursor便会自动执行该文件，整个过程不弹出任何提示、确认或警告——直接导致任意代码执行。
作为当前最炙手可热的AI编程工具之一，Cursor坐拥700万活跃用户、100万日活、100万付费用户，超过5万家企业正在使用，市场估值据称高达600亿美元。按理说，它的安全实践应当极为严谨，然而这个漏洞却揭示出，事情并非想象中那般理想。
研究团队于2025年12月15日首次发现该漏洞，当日便提交了报告，随后又多次补充提交。六个多月过去，Cursor迭代了197个新版本，但问题依旧悬而未决。
这个漏洞并非理论上的空谈，也无需复杂的攻击链、提示注入、模型操纵、越狱或内存损坏等花哨手段。开发者只需打开一个项目，而该项目根目录下恰好存在一个恶意git.exe文件，即可触发利用。
Cursor用户当前应如何应对
对于企业用户而言，若使用的是托管Windows系统，管理员可临时借助AppLocker或Windows应用程序控制策略，禁止从开发者工作区目录执行特定可执行文件。建议采用基于路径的拒绝规则，限定在仓库根目录，例如 %USERPROFILE%\sourcerepos\*\filename.exe，避免使用哈希规则，因为攻击者提供的二进制文件哈希值可能不断变化。Windows并未内置通用的规则，能够仅当特定父进程启动时才阻止子进程执行，因此要实现父进程感知，通常需要依赖EDR或自定义端点安全产品。
个人用户方面，在IDE修复完成之前，建议仅在隔离的虚拟机、Windows沙盒或其他一次性环境中打开不信任的仓库。不要指望文件哈希黑名单能解决此问题。
对简单问题的诡异反应
此次漏洞披露中最令人困惑的，莫过于Cursor几乎没有给出实质性回应。七个月间，团队尝试了所有渠道进行沟通。最初报告直接发送至Cursor security.txt中指定的安全邮箱，未收到确认后又发送了后续邮件。团队还通过公开喊话，试图找到合适的联系人。
最终，Cursor的CISO总算回应，承认内部自动化故障导致HackerOne流程未能走通。团队被邀请加入私人漏洞奖励计划，并重新提交了报告。
然而，报告被定性为“信息性”且“超出范围”，直接关闭。团队提出质疑后，HackerOne重新打开问题，重现了漏洞，并确认相关信息已传递给Cursor。随后，一切再度石沉大海。更新请求无回应，后续跟进无回应，HackerOne升级无效，直接联系领导层同样无果。
一个月又一个月过去，没有任何证据表明修复工作已启动、工程团队在调查、或用户将被告知风险。与此同时，Cursor持续发布新版本，70多个版本发布、公告、功能更新不断推出，漏洞却始终悬而未决。多次请求状态更新，均如泥牛入海。
沟通的焦点逐渐从漏洞本身，转向了一个更令人不安的问题：这些安全流程，究竟在发挥什么作用？
技术层面其实相当简单。Cursor打开项目时，会从多个位置寻找Git的二进制文件，其中一个位置竟然就是工作区本身。若攻击者在仓库根目录放置一个假冒的git.exe，Cursor便会自动执行它，没有任何警告，连提示都没有。
为了安全演示，团队使用了一个无害的示例：将Windows计算器重命名为git.exe，放在仓库根目录。打开项目后，计算器窗口便弹出。
下面的截图展示了结果。那些计算器窗口并非手动打开，而是Cursor自动反复执行重命名的二进制文件，一个接一个弹出。换言之，这并非一次性的启动事件，也非用户操作触发。Cursor在正常操作中，反复调用了工作区内的可执行内容。
若将计算器替换为恶意代码，后果可想而知。
最终结果是：在当前用户权限下执行任意代码，如下方Sysinternals进程监视器日志所示（最后一次验证时间为2026年4月30日，针对Windows上的Cursor 3.2.16版）。
这个漏洞简单得近乎无趣，但恰恰是这一点最令人担忧。在正常操作期间，Cursor从仓库中执行攻击者控制的二进制文件，完全无需用户交互。如此简单的问题，拖了数月仍未修复，每个正在使用Cursor的个人和组织，都应高度重视。
此次披露为何不同寻常
大多数协调披露都遵循标准流程：
- 报告漏洞
- 启动沟通
- 讨论严重性
- 工程团队调查
- 开发修复方案
- 保护用户
- 公开披露
这套流程之所以有效，是因为各方目标一致：降低风险。
但此次，事情根本未能推进到降低风险那一步。七个月过去，供应商完全没有参与，此刻有必要追问：如此简单、影响如此巨大的漏洞，究竟会不会被修复？
安全研究员深知，修复需要时间，尤其在大平台环境中。但数月过去，没有沟通、没有更新、没有明显进展，耐心便难以维持。用户应当获得基本保护，当供应商一边继续分发有问题的软件，一边停止沟通，研究员便面临一个尴尬的抉择：
- 保持沉默，让用户在错误的安全假设下继续工作。
- 或者公开披露，让组织能够做出明智的风险决策。
用户有权知晓这些信息。完全披露是漏洞披露的终极手段，仅在所有其他路径均走不通时才使用。它之所以存在，是因为当供应商保持沉默时，用户不应被蒙在鼓里。
当创新停止倾听时会发生什么？
最明显的问题也是最简单的：为何这么久仍未修复？
这个漏洞既不复杂，也不难复现，后果却极为严重。Cursor的反应，让人不得不思考一些更深层次的问题：
- 现代漏洞奖励计划是否已超负荷运转？
- 是否因为Mythos等模型能力过强，导致报告数量激增？
- Cursor是否只顾着收购SpaceX，而将用户安全抛在脑后？
- 当几十亿美元的利益摆在面前，用户安全究竟还占多大分量？
安全行业多年来一直鼓励研究人员通过正规渠道报告漏洞。这些渠道的有效性，依赖于供应商快速响应、评估并采取行动。然而，随着AI产品越来越多，安全问题也成倍增长。许多发现新颖独特，传统漏洞类别根本套不进去。而我们沿用近二十年的分类流程，也开始失灵，因为其核心假设在AI时代已站不住脚。
若披露渠道真的不堪重负，行业应当公开说明。研究人员、客户、用户，都应了解真相。
遗憾的是，随着优先级问题日益令人不安，情况可能更糟。与许多公司一样，Cursor正处于高速增长、投资和行业聚焦的中心。公司扩张迅速，但从外部观察，很难将这种增长与直接任意代码执行漏洞上毫无进展这件事协调起来。
增长越快，解决安全问题的责任就越大，同时也要将用户视为有价值的客户，而非购买实验品的人。用户信任生产软件，将源代码、凭证、知识产权，甚至越来越多的自主功能交由它处理。
信任需要责任，责任需要沟通。当用户、研究员和披露平台花费数月寻求基本状态更新都无果时，这种责任便变得难以看到，也难以相信。
更大的问题
此次披露，关乎的不仅仅是git.exe这一个文件，而是软件信任的本质。AI公司经常要求用户授予对代码、仓库、终端、秘密和工作流的无上权限，建议与行动之间的界限越来越模糊。
行业总说这些系统值得信任，因为能提高生产力。但历史一次次告诉我们，有用不等于值得信任。信任是挣来的，不是白给的。它体现在公司如何回应安全报告、如何与用户沟通、如何安排修复优先级。当这样一个简单的漏洞拖了数月未修，沟通也无下文，用户就不得不重新评估，这份信任究竟值不值得。
为何我们要全面披露
与其他安全研究团队一样，我们也更倾向于协调披露。目标永远是安全第一，公开第二。
但协调披露仅在双方都配合时才有效。第一次报告七个月后，没有任何迹象表明用户得到了保护、修复在进行、或受影响的公司收到了通知。此时，继续隐瞒信息，就不是为用户服务，而是在为沉默服务。
因此，我们决定公开所有细节。使用Cursor的组织，应当有机会评估风险、实施补救措施、做出明智的决定。用户安全必须放在第一位，即使公开披露会让人感到不适。
尤其是当它让人感到不适的时候。
