说明：本文基于安全厂商 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 即将执行命令”的最后一步。项目加载本身已经包含了值得审计的决策。

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

对个人开发者，实用的做法很简单：来源不清楚的仓库，第一次不要放到存着日常凭据、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 只是把过去由人手动确认的一些步骤提前了，安全措施也应该提前：在工具真正开始工作前，先把不可信仓库和可信开发环境隔开。

参考来源

• Mindgard：Cursor 0day: When Full Disclosure Becomes the Only Protection Left
• Hacker News：Cursor 0day: When Full Disclosure Becomes the Only Protection Left
• Microsoft Learn：AppLocker overview
• Microsoft Learn：Windows App Control overview

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