Cursor IDE 零日漏洞:7 个月、197 个版本、零回复——一款 60 亿美元估值的 AI IDE 是怎么「晾」一个低级 bug 的

Mindgard 在 2026 年 7 月 14 日发布了一篇完整的公开披露:他们 2025 年 12 月 15 日报告给 Cursor 的一个 RCE(远程代码执行)漏洞,等了 7 个月、跨了 197 个新版本、追问无数次,Cursor 那边一声没吭。

我看完披露细节,第一反应不是「这漏洞多牛」,而是「这漏洞怎么这么低级」。技术上一点都不复杂——只要在仓库根目录放一个恶意的 git.exe,Cursor 在 Windows 上加载项目时就会自动执行它。零点击、零弹窗、零警告。

事件内容

漏洞的触发链非常短:

1. Cursor 在加载项目时会扫描多个路径来寻找 Git 二进制文件,workspace 根目录是其中之一; 2. 如果攻击者在仓库根目录塞一个 git.exe,Cursor 会把它当成系统 Git 来调用; 3. Cursor 会在正常 IDE 操作里反复触发这个二进制(git rev-parse --show-toplevel 这种命令),整个过程不需要任何用户交互; 4. Mindgard 的 POC:把 Windows 计算器改名为 git.exe,放在仓库根目录,打开 Cursor——计算器被反复拉起。

执行权限就是当前开发者用户的权限。能拿到的东西包括 API key、.env 文件、SSH 密钥、本地数据库,以及整台开发机的访问权。

Mindgard 的披露时间线(来自原始博客):

– 2025-12-15:漏洞发现,通过 HackerOne 提交给 Cursor; – 2026-01-15:Cursor 的 CISO 手动把研究人员加进 bug bounty 项目,承认是「自动化失败」; – 2026-01-16:报告先被以「out-of-scope」关闭,被挑战后重新打开; – 2026-02 ~ 2026-06:多次追问无回复; – 2026-06-01:Mindgard 公开说要披露; – 2026-07-14:完整披露。漏洞在 4 月 30 日测试的 v3.2.16 里依然存在。

没拿到 CVE。原因是 Cursor 在整个流程里没正式接报告,所以 CVE 体系根本没进这事儿。

披露里最让我不舒服的一句话是 Mindgard 写的:「协调披露只有在双方都愿意协调的时候才有效。」他们选了用户,没选沉默。

深度剖析

我关心的不是技术,而是 Cursor 这家公司为什么这么做。

先看 Cursor 的规模:披露里直接给了数字——700 万+ 月活、100 万+ 日活、100 万+ 付费用户、5 万+ 公司客户、估值 600 亿美元。这是 AI 编程工具赛道里仅次于 GitHub Copilot 的老二。

然后看那个 bug:它是开发环境最朴素的搜索路径逻辑,理论上写测试时一行 unit test 就能发现。但 Cursor 197 个版本没修,这件事只能有一种解释——Cursor 的安全流程在那个时段是断的。CISO 是手动加的研究人员(意味着报告没走正常通道)、报告被自动化标记成 out-of-scope(意味着 triage 流程失灵)、追问无人回复(意味着安全团队没有 SLA)。对一款工具 700 万开发者日常使用的 IDE 来说,这三个环节同时断掉,本身就是比漏洞更严重的事。

再看 DuneSlide。2026 年 4 月 2 日披露的另一个 Cursor 高危漏洞(CVE-2026-50548/50549,CVSS 9.8,通过 MCP 服务器或搜索结果触发零点击沙箱逃逸)Cursor 3.0 就修了。说明安全团队不是没能力,也不是不修所有 bug——他们选择性响应。Mindgard 这个报告被他们判定为「out-of-scope」,大概率是因为它不属于 AI / Agent 范畴,而是「经典 IDE 安全」,被归到低优先级。但讽刺的是,这种「经典 IDE 安全」反而是开发者每天踩的最基础的坑。

最后看披露选型。Mindgard 没走 90 天标准周期,从报告到披露花了整整 7 个月——他们给了 Cursor 远超行业惯例的窗口。完全披露的内容也没藏着掖着,把攻击路径、POC、用户缓解措施、官方应做但没做的事全列出来了。这是一次教科书级别的负责任披露,只是对象不接招。

值得关注的原因

第一,这是 AI 编程工具的安全问题第一次以「零日 + 公开披露 + 厂商零响应」三连击出现。7 月 13 日 Grok CLI 静默上传代码 + 密钥的事件(07-13 已报道)是「工具自带隐私裸奔」,Cursor 0day 是「工具本身的代码执行基座就有洞」。这是两个不同的攻击面:前者威胁用户数据,后者威胁用户机器。AI coding 工具的攻击面比传统 IDE 大得多,但目前的工具厂商普遍没有把安全等级提到对应的高度。

第二,它给所有 AI coding 工具厂商提了一个醒:「AI 时代的安全不是 LLM alignment,是端到端信任链」。你花一年时间让模型不输出有害内容,不如花一周时间检查 IDE 自己是不是会执行仓库里的二进制。这是 Cursor 给同行的教训。

第三,普通开发者的应对方案很明确也很麻烦——Mindgard 在披露里直接列了:

– 企业/托管 Windows:用 AppLocker 或 Windows App Control,按路径(%USERPROFILE%sourcerepos*filename.exe)拒绝工作区目录的 .exe 执行,不要用哈希黑名单(攻击者可以每次换哈希); – 个人开发者:不信任的仓库只能在隔离环境(Windows Sandbox、VM、临时容器)里打开; – 不要靠 hash 阻断,因为攻击者的二进制每次都不同。

对个人开发者来说,这条建议的实操成本挺高——你以后 review GitHub PR、看开源代码、面试候选人代码,都得在隔离环境里跑 Cursor。

风险与待观察

– Cursor 是否会快速修复?截至 7 月 14 日披露时,官方没有任何公开声明。Hacker News 上有人猜测更可能的修复路径是 Cursor 在某个时间点悄悄加个路径过滤,而不是公开发 patch notes——因为公开承认「我们 7 个月没修一个低级 RCE」对估值 600 亿美元的 IDE 是公关灾难。 – 是否有 CVE?目前没 CVE。如果 MITRE 后来给分配了(CVE-2026-XXXXX),这会变成一个被引用到 2030 年的「负责任披露失败案例」。 – 有没有野外利用?Mindgard 没公开说看到,但 GitHub 上已经有大量恶意 git.exe POC 仓库,Cursor Windows 用户从披露日起窗口期大约在 24-72 小时。 – 它是否会影响 Cursor 的 ARR?短期不会——700 万月活的迁移成本极高。但企业 CISO 那边大概率会把 Cursor 列入「需提供安全审计报告才能用」的清单,这对销售周期是真实打击。 – 其他 AI IDE 是不是也有同类 bug?WindSurf、Cline、Roo Code、Continue、Zed AI 都还没做过类似披露,但搜索路径逻辑在 IDE 里几乎是通用模式。Cursor 这次披露,等于给整个行业做了一次免费渗透测试。

来源:Mindgard 原始披露(https://mindgard.ai/blog/cursor-0day-when-full-disclosure-becomes-the-only-protection-left)、Cybersecurity News(https://cybersecuritynews.com/cursor-ai-coding-agent-vulnerability/)、byteiota(https://byteiota.com/cursor-ide-rce-unpatched-git-exe)、网易科技(https://www.163.com/dy/article/L1RO4LPV05561FZH.html)、Developers Digest(https://www.developersdigest.tech/blog/cursor-0day-git-exe-vulnerability)