打开仓库就能中招：Cursor 的 git.exe 0day，暴露了 AI IDE 最容易被忽略的一层信任边界

Wed, 15 Jul 2026 08:00:00 +0800

说明：本文基于安全厂商 Mindgard 于 2026 年 7 月 14 日发布的公开披露整理。文中关于漏洞触发条件、受影响版本和沟通时间线，均以研究方的测试与陈述为依据；Cursor 后续是否修复、具体影响范围如何，应以 Cursor 的官方安全公告和更新说明为准。

很多开发者把“打开一个仓库”当成一件近乎只读的事：看 README、扫目录，决定要不要运行项目。

但集成开发环境（IDE）不是文件浏览器。加载项目时，它会识别版本控制、寻找解释器、读取配置、启动语言服务、调用扩展。这个过程会把目录里的部分内容带入本机工具链。

Mindgard 7 月 14 日公开的 Cursor Windows 问题，就落在这段容易被忽略的初始化流程里。按研究方描述，Cursor 加载项目时会寻找 Git 二进制文件；若工作区根目录存在同名的 git.exe，Cursor 可能在没有点击、确认或提示的情况下执行它。研究方称，他们最初在 2025 年 12 月报告问题，到 7 月公开文章发布时，仍能在测试版本中复现。

重点不在于 Agent 获得终端权限后会不会乱跑命令，也不在于恶意提示怎样污染模型上下文。更早的一步已经发生：IDE 加载不可信仓库时，是否把仓库里的内容混进了本机原本该使用的工具。

问题不在 Agent 开始执行之后

Cursor、Claude Code、Codex 能读代码、改文件、跑测试、调终端，所以安全讨论常常围着两个问题转：用户是否授权了命令执行，一次工具调用是否该弹确认。

这种讨论默认了一个前提：真正开始执行任务前，环境已经可信。

Mindgard 披露的情况不符合这个前提。按其文章描述，问题出在 Cursor 查找 Git 的阶段。Cursor 需要确认当前项目的版本控制状态，因此解析 Git 工具位置；研究方发现，工作区本身被纳入查找范围。一个本应只放项目文件的目录，也就可能被当成工具所在位置。

这是传统的路径解析（path resolution，路径解析）问题，和模型能力无关。不过 AI 原生 IDE 改变了它的使用场景：开发者会从 issue、演示项目、开源仓库或聊天链接直接拉代码，然后让工具立即理解项目。仓库既是待阅读的源代码，也是 IDE 初始化、Agent 规划与工具发现的起点。

如果初始化时没有把这个起点当成不可信输入，后面再细的权限设计也补不回已经发生的执行。

打开仓库，实际上触发了哪些信任决定

一个新仓库被打开后，开发者看到的是编辑器窗口，后台却会同时开始一连串初始化动作。

IDE 要判断根目录是不是 Git 仓库，寻找 git，读取忽略规则和项目配置；语言服务会扫描依赖、索引符号；扩展则根据文件类型和工作区设置决定是否启动。有些项目还会提示安装插件、恢复开发容器或加载任务定义。

没有这些动作，IDE 很难做到开箱即用。真正需要区分的是两种对象：

项目数据：源代码、文档、配置、依赖清单；
宿主工具：Git、解释器、构建程序、扩展、系统命令。

仓库里的源代码、文档和配置，应该先按外部输入处理；Git、解释器、构建程序、扩展和系统命令，则应来自受管理的开发环境。两类内容混在一起后，仓库就不只是描述“项目需要什么”，也会影响“宿主机实际执行什么”。

Mindgard 的演示使用了无害程序作为概念验证，并展示了 Cursor 启动与同名程序进程创建之间的关联。无需复现攻击步骤，问题已经足够清楚：如果 IDE 在加载阶段执行工作区内的同名二进制，“我只是打开看看”并不等于没有执行风险。

这不是普通功能 bug。它涉及的是仓库和宿主工具之间原本应当清晰的边界。

和 Prompt Injection、Agent 白名单的边界在哪

AI 编程工具的安全新闻很多，很容易被压缩成一句“Agent 很危险”。这种说法没有帮助，因为不同问题的控制点不一样。

此前写 Prompt Injection（提示词注入）时，关注的是 Agent 读取 issue、评论、文档或网页后，会不会把恶意文本当作指令，偏离原来的任务。这条链路从不可信文本进入决策开始。

关于 EDR（端点检测与响应）和白名单的文章，则看的是 Agent 已经拿到终端、浏览器或网络能力以后，下载、重试、凭据访问为什么会触发端点防护。这是已获授权的自动化进入系统行为的问题。

Cursor 这次披露更靠前：IDE 还在加载 workspace（工作区）、寻找基础工具时，仓库内的可执行内容是否已经混入宿主工具链。它不必等待模型读到恶意指令，也不需要用户给 Agent 下达危险任务。

一个不可信仓库可能同时包含误导 Agent 的文本、可疑工作区配置和恶意二进制，因此三层风险会叠加。但处理时仍要分别落点：

风险层	关键问题	首要控制点
上下文层	Agent 读到了谁写的指令？	内容隔离、指令层级、工具确认
执行层	Agent 被授权后实际做了什么？	任务边界、最小权限、EDR 审计
加载层	IDE 在打开仓库时信任了什么？	工具路径、工作区隔离、宿主机执行策略

确认框不应只放在“Agent 即将执行命令”的最后一步。项目加载本身已经包含了值得审计的决策。

不可信仓库，先别拿主力开发环境试水

对个人开发者，实用的做法很简单：来源不清楚的仓库，第一次不要放到存着日常凭据、SSH key、浏览器登录态和公司代码的主力 Windows 环境里打开。

这不等于把所有 GitHub 项目都当恶意软件。常见开源依赖、内部仓库和经过 code review 的项目，仍可走正常流程。需要额外处理的，往往是陌生 issue、私信、压缩包、临时 demo、漏洞复现仓库，或一句“帮忙看一下这个项目”背后的链接。

第一次接触时，把它放到隔离环境里会更合适：

用 Windows Sandbox、虚拟机或独立测试设备打开来源不明的项目；
在隔离环境中不要登录个人浏览器、代码托管平台或公司 VPN；
不要为了“让项目跑起来”立刻批准扩展安装、工作区任务或系统级依赖安装；
如果只是审阅文件，优先使用不会自动启用完整开发环境的方式查看内容；
对需要继续开发的仓库，先确认来源、提交历史、依赖和团队归属，再迁入主力环境。

看起来有些保守，但成本通常不高。反过来，陌生仓库一旦进入带完整登录态和本机权限的环境，事后再追查它读过、写过或启动过什么，代价会大得多。

企业不能只靠提醒开发者小心

“不要打开不可信代码”在企业里只是第一道提醒。研发要看 issue、跑 PoC、评估供应商示例；彻底禁止外部仓库既不现实，也容易把行为推到缺少记录的个人环境中。

更实际的是把开发环境分层，而不是让所有人都在同一台高信任桌面上处理所有代码。

外部 demo、漏洞验证、客户提供的代码和临时脚本，先进入没有生产凭据、没有内部网络直通权限的分析环境。这个环境可以是托管虚拟桌面、受控 VM，也可以是有明确销毁周期的沙箱。

对受管理的 Windows 设备，可评估 AppLocker 或 Windows App Control 一类机制，限制开发工作区中不应直接启动的可执行内容。规则必须结合公司目录、签名策略和开发流程来设计。只拉黑一个文件名并不可靠，攻击者能改名，研发也会有合理的本地构建需求。目标是让“从临时工作区启动未知二进制”成为可见、可审计、可收紧的事件。

EDR 也不该因为父进程叫 Cursor 或其他 AI IDE 就自动放行。进程树、命令行、工作区路径、文件来源和用户身份仍应被记录。出现异常时，安全团队需要知道的不是“某个 IDE 可疑”，而是某位用户在什么隔离等级的工作区加载项目后，哪个子进程从哪里启动。

这些控制不能代替厂商修复，只能为产品缺陷增加几层限制。即使路径解析出了问题，未知仓库里的程序也不该轻易拿到主力开发环境的执行条件。

AI IDE 的初始化，也该纳入安全设计

AI IDE 的吸引力在于省掉许多手工操作：识别仓库、理解依赖、补全环境，再把 Agent 带进真实任务。但“自动识别”并不只是体验优化。它始终在判断，当前文件、路径和工具能被信任到什么程度。

对开发者而言，打开项目不是绝对安全的起点，而是一次权限和信任的升级。对产品团队而言，Git 查找、语言服务启动、扩展加载和任务发现，也不只是体验细节。

Agent 权限解决“它接下来能做什么”；Prompt Injection 解决“它为什么会被带偏”；工作区加载安全则要先解决“它还没开始执行任务时，哪些内容已经被当成工具”。

把问题拆开，修复路径才会清楚。AI IDE 只是把过去由人手动确认的一些步骤提前了，安全措施也应该提前：在工具真正开始工作前，先把不可信仓库和可信开发环境隔开。

参考来源

以上公开来源用于说明研究方的披露、社区讨论与 Windows 应用控制机制。漏洞触发条件和受影响版本主要来自 Mindgard 的测试陈述；本文不构成对 Cursor 当前版本状态的独立认证，也不能替代组织针对自身设备、代码和凭据范围进行的安全评估。

IDE安全 on 奇诺分享 | 重在分享