Hacker News 中文摘要

RSS订阅

Cursor 0day漏洞：当完全披露成为最后的保护 -- Cursor 0day: When Full Disclosure Becomes the Only Protection Left

原文链接 | HN讨论 | 2026-07-15 05:36:06

文章摘要

Cursor IDE存在严重安全漏洞：当用户在Windows系统打开项目时，若项目根目录包含恶意git.exe文件，Cursor会自动执行该文件，无需用户交互或确认，导致任意代码执行风险。该漏洞影响700万以上活跃用户。

文章总结

好的，这是根据您的要求，对原文进行的中文重述，保留了核心细节，并删减了与主题无关的评论性内容。

标题：Cursor 零日漏洞：当完全披露成为最后的保护

核心要点： 在加载项目后，Cursor 会在包括当前工作区在内的多个位置查找 Git 二进制文件。攻击者可以在仓库根目录放置一个恶意的 git.exe 文件，当开发者打开该仓库时，Cursor 会在无需用户任何交互或提示的情况下自动执行该文件，并且此过程会反复发生。

漏洞详情： 这是一个非常简单的漏洞。当开发者在 Windows 系统上使用 Cursor 打开一个仓库时，如果该仓库的根目录下包含一个恶意的 git.exe 文件，Cursor 会自动执行它。整个过程无需任何点击、提示、批准对话框或警告，最终导致任意代码执行。

漏洞发现与报告过程： 该漏洞由 Mindgard 于 2025 年 12 月 15 日发现，并于当天通过 Cursor 官方指定的安全报告邮箱进行报告。在未收到确认后，Mindgard 多次跟进。最终，Cursor 的 CISO 回应称，内部自动化流程故障导致报告未被正常处理，并邀请 Mindgard 加入其 HackerOne 漏洞赏金计划。

在 HackerOne 上，该报告最初被标记为“仅供参考”并判定为超出范围。在 Mindgard 提出异议后，HackerOne 重新打开报告，成功复现了该问题，并确认已将详情转交给 Cursor。然而，此后沟通便陷入停滞。Mindgard 多次请求更新，均未收到回复。在超过 6 个月、Cursor 发布了 197 个以上新版本后，该漏洞在最新测试版本中依然存在。

技术细节： 当加载项目时，Cursor 会在多个位置查找 Git 二进制文件，其中就包括工作区本身。如果攻击者在仓库根目录放置了恶意的 git.exe，Cursor 会在其路径解析逻辑中自动执行它，而不会发出任何警告或请求批准。

为了安全地演示该问题，Mindgard 将 Windows 计算器程序重命名为 git.exe 并放置在仓库根目录。仅需在 Cursor 中打开该仓库，计算器程序就会被执行。并且，只要项目保持打开状态，Cursor 会反复执行该重命名的二进制文件，导致多个计算器窗口出现。这表明，这不是一次性的启动事件，而是 Cursor 在正常运行期间会反复执行工作区内的可执行内容。

对用户的建议： - 企业/托管 Windows 系统： 作为临时缓解措施，管理员可以使用 AppLocker 或 Windows 应用程序控制策略，禁止从开发者工作区目录执行 git.exe。建议使用基于路径的拒绝规则（如 %USERPROFILE%\source\repos\*\git.exe），而非基于哈希的规则。 - 个人用户： 在 Cursor 发布补丁之前，仅在隔离的虚拟机、Windows Sandbox 或其他一次性环境中打开不受信任的仓库。

时间线： - 2025年12月15日：Mindgard 发现漏洞并立即报告。 - 2026年1月15日：Cursor CISO 回应，邀请加入 HackerOne 项目。 - 2026年1月16日：报告在 HackerOne 上被关闭，后经异议后重新打开并确认。 - 2026年1月20日：HackerOne 确认已将详情转交 Cursor。 - 2026年2月至4月：Mindgard 多次请求更新，均未收到回复。 - 2026年6月1日：Mindgard 通知 HackerOne 将进行公开披露。 - 2026年7月14日：发布此博客文章。

结论： 由于在长达七个月的时间里，供应商（Cursor）未能进行有效沟通或修复，Mindgard 选择进行完全披露。其目的是让使用 Cursor 的组织和用户能够了解风险，评估自身暴露情况，并采取相应的补偿控制措施，从而做出明智的安全决策。

评论总结

根据评论内容，总结如下：

主要观点与论据：

  1. 漏洞严重性争议（评分：无）

    • 部分评论认为漏洞严重，因Cursor会无提示执行任意exe文件（如git.exe），且开发者数月未回应。
    • 另一部分认为漏洞被夸大：攻击者需先放置恶意exe到用户系统，此时系统已遭入侵，类似替换.bashrc或自动运行npm install。
    • 关键引用：
      • "It's pretty weird for cursor to run arbitrary exe file without prompting" (Illniyar)
      • "if they've placed something in your filesystem like that already, you've already been compromised" (jjcm)

  2. 漏洞成因与设计质疑（评分：无）

    • 评论质疑Cursor为何设计此功能，猜测是开发者git故障后，AI代理“修复”时在仓库中放置了git.exe并条件调用。
    • 认为此功能冗余，且与VSCode的“信任项目”对话框矛盾。
    • 关键引用：
      • "I'm struggling to understand the process that went into this 'feature' existing" (aliasxneo)
      • "Why is cursor subsequently executing anything?" (minraws)

  3. 披露流程与公司态度（评分：无）

    • 批评Cursor公司未及时修复漏洞，且安全研究人员在HackerOne上数月无果后公开披露。
    • 认为公司不重视安全，而公开披露更多是出于公关目的。
    • 关键引用：
      • "It's sad yet understandable how a company would not prioritize security" (firer)
      • "The devs do not consider it a bug" (chrisjj)

  4. 实际利用条件（评分：无）

    • 漏洞需用户已下载恶意文件，且Windows ACL可能阻止未签名程序运行。
    • 仅影响仓库根目录的git.exe，不涉及npm供应链攻击。
    • 关键引用：
      • "You'll have to have ACL disabled completely for this to be exploitable" (Illniyar)
      • "I guess this is only specific to a file in the root of the repo" (awongh)

平衡性总结：
评论对漏洞严重性存在分歧：一方强调无提示执行任意文件的危险性，另一方认为前提条件苛刻（需已入侵系统）。多数评论质疑Cursor的设计合理性，并批评公司响应迟缓。部分评论指出，类似风险在VSCode等IDE中已存在（如自动运行npm install），但Cursor的特定实现方式（如条件调用git.exe）显得冗余且危险。