Cursor Windows任意代码执行漏洞，沙箱打开前需谨慎

Cursor 3.2.16 Windows上的安全问题：7月14日披露的PoC - 未检查仓库中的git.exe在打开时运行

7月14日，Mindgard披露了一个PoC，在该PoC中，Windows上的Cursor在打开项目时会查找并执行位于仓库根目录中的git.exe。为了演示，研究人员将Windows计算器重命名为git.exe并将其放在项目文件夹中。不需要单独点击文件或确认提示。

这改变了Cursor的实践规则：陌生的仓库在隔离环境中打开之前，不能仅仅被视为源代码集合。风险不在Git本身，也不在互联网上的每个项目，而在于可执行文件搜索可能会考虑工作区的内容。

具体确认的内容

公开命名的检查涉及Windows上的Cursor 3.2.16，日期为4月30日。攻击条件也很具体：用户必须在本地获得被污染的仓库并在编辑器中打开它。这不是关于"远程零点击"无需人工参与的断言，也不是macOS或Linux的证据。

机制比炫目的演示更重要。如果工具在打开工作区时搜索git.exe，使得项目根目录中的文件成为合适的候选者，则仓库不仅影响代码文本和配置，还影响要运行的程序的选择。那么熟悉的"查看项目"操作就成为了执行的边界。

经过七个月的披露后，Mindgard发布了详细信息。讨论很快超出了一份报告的范围：Hacker News上的相应帖子获得了453分和202条评论。这不是对漏洞普遍性或开发者对这类风险熟悉程度的衡量，而是对这个特定帖子的兴趣和讨论度的指标。

证据的界限在哪里

现在最危险的错误可能不是低估PoC，而是将其扩展超出事实。更新的版本3.11没有被研究人员在所述的测试中公开检查。因此，"最新的Cursor肯定易受攻击"这一说法是未经证实的。

Cursor将这一场景列为bug bounty计划之外的范围，理由是共同责任和工作区信任。这是一个有力的反驳：开发环境确实不能完全代替用户对项目来源的评估，而对工作区的信任应该影响有风险的操作。

但这里仍然存在一个实际问题。发表的内容没有给出独立的最终验证，即工作区信任是否恰好阻止了所述的Git探测。在得到答案之前，将信任设置合理地视为额外的屏障而不是唯一的保护是合理的。

解决方案：分离查看和信任

对于陌生的仓库，短决策模式很有用。

打开前，检查解包文件夹的根目录是否存在可执行文件，尤其是环境可能搜索的工具名称。

如果项目仅用于初步检查，请在Windows Sandbox或一次性虚拟机中打开它。

不要将工作秘密、令牌和其他敏感数据连接到这样的环境。

在托管的Windows环境中，使用基于路径的AppLocker规则或Windows应用控制策略，限制从出现外部仓库的路径执行。

不要仅依赖哈希阻止：当恶意文件可以重建或替换时，它不能解决问题。

这不是停止使用外部库、示例和测试项目的理由。这是区分"我想阅读代码"和"我准备让文件夹参与搜索可执行程序"的理由。

当团队定期研究外部仓库时，基础设施边界很有用：首先在一次性环境中解包并检查项目，不挂载秘密并记录执行事件。这种模式可以在provod.ai中建立为agentic编码的独立电路，不假设服务本身运行Cursor。

provod.ai — 符合俄罗斯要求的企业AI工作

对于涉及个人数据的场景，重要的不仅是模型，还有流程的组织：平台设计时考虑了俄罗斯立法的要求，适用性由数据组成和客户设置决定。

一个目录中提供了最新的文本和媒体模型：来自OpenAI的GPT、来自Anthropic的Claude、来自Google的Gemini、来自xAI的Grok、DeepSeek、Qwen、GLM、Kimi和MiniMax；对于图像——Nano Banana 2 Pro和GPT Image；对于视频——Seedance、Kling、Veo和Google Omni的最新版本。还提供了用于推理、搜索、文档、嵌入、音乐和音频的模型。

企业流程要求不会增加模型的费率：成本与提供商的官方价格保持1:1，不含provod.ai的加价。

了解企业场景的条件：注册表单·模型价格·根据152-ФЗ的数据保护·数据处理策略

对你的团队来说，什么更昂贵：花几分钟对每个外部仓库进行隔离的首次运行，还是有权在工作环境中直接用秘密打开它们？

For further actions, you may consider blocking this person and/or reporting abuse