摘要：Windows版Cursor安全问题显示，打开陌生代码仓库本身就可能触发代码执行。AI编程工具把开发终端、Agent、Git、Shell和供应链流程连接起来，也扩大了开发环境的攻击面。
开发人员从GitHub下载一个示例项目。
文件解压后，他用Cursor打开项目，准备让AI检查代码结构。编辑器刚刚完成加载，仓库根目录中的一个程序便获得了执行机会。
没有点击运行按钮，没有打开终端，也没有向AI发送指令。
2026年7月14日披露的一项Windows版Cursor安全问题显示，只要仓库根目录中放置一个名为git.exe的恶意程序，Cursor在寻找Git工具时便可能执行它。研究人员使用Windows计算器制作测试样本，将其改名为git.exe。打开项目后，计算器被自动启动；项目保持打开时，该程序还会被重复调用。
一次普通的“打开代码”，由此变成了代码执行入口。
截至2026年7月15日，Cursor公开更新日志尚未列出这项问题的修复说明。研究方称，问题在公开前最后测试的版本中仍然存在；Cursor已表示着手处理。用户仍需关注厂商后续发布的安全版本和公告。
一、恶意程序为什么会被当成Git执行
开发工具需要频繁调用Git。
打开项目后，编辑器会执行类似下面的命令：
1 | git rev-parse --show-toplevel |
这条命令用于确认当前目录是否属于Git仓库，以及仓库根目录位于哪里。
执行命令前，程序需要找到git.exe。
安全问题出在查找范围。Cursor除了查找系统安装目录，还会在当前工作区中寻找Git程序。攻击者将恶意程序命名为git.exe并放到项目根目录后，编辑器可能把它当成正常Git工具调用。
恶意程序以当前登录用户的权限运行。
研究人员使用进程监控工具记录到，Cursor.exe直接创建了仓库中的git.exe进程，并向它传入正常Git参数。最后一次公开验证使用的是Windows版Cursor 3.2.16，验证日期为2026年4月30日。
这类问题不依赖模型幻觉、提示词注入或复杂的多步骤利用。
攻击者只需要完成两件事：
- 把恶意程序放进代码仓库；
- 让开发人员用存在问题的工具打开该仓库。
代码仓库因此不能继续被理解为一组等待阅读的文本文件。
二、一个仓库里有哪些可以执行的内容
开发人员通常重点检查以下文件：
- 源代码；
- 配置文件；
- 依赖清单；
- 文档；
- 测试用例。
现代开发环境还会读取大量带有执行能力的内容。
1. 可执行程序和脚本
仓库中可能包含：
1 | .exe .dll .bat .cmd .ps1 .vbs .sh .py .js |
部分文件由开发人员主动运行，也有一些可能被编辑器、构建工具、安装程序或AI Agent自动调用。
2. Git钩子
Git支持在提交、合并、签出和推送等环节执行钩子脚本。
此前披露的另一项Cursor漏洞CVE-2026-26268，就利用了嵌套Git仓库中的恶意钩子。当AI Agent执行常规Git操作时，隐藏脚本获得执行机会。该问题已在厂商配合下完成修复。
3. 包管理脚本
Node.js项目中的package.json可以定义安装脚本。
Python、Rust、Java、.NET和其他开发体系也存在构建脚本、安装钩子、插件机制和代码生成工具。
开发人员执行一次安装依赖，可能同时执行仓库作者提供的脚本。
4. 编辑器工作区配置
.vscode、.cursor以及其他编辑器配置目录，可以定义：
- 调试任务；
- 构建命令；
- 终端配置；
- 推荐扩展；
- 环境变量；
- Agent规则；
- MCP服务器；
- 自动化流程。
工作区配置由仓库携带。打开项目后，开发工具可能主动读取这些内容。
5. 开发容器配置
.devcontainer目录可以定义镜像、挂载目录、端口、启动命令和初始化脚本。
开发容器能够提供隔离，也可能因为过度挂载宿主机目录、Docker套接字或凭据目录，获得超出项目需要的权限。
6. Notebook与富文档
Jupyter Notebook除了代码单元，还可能保存HTML、JavaScript输出和外部资源。
部分文档预览器、图表插件和浏览器组件也具有脚本执行能力。
7. AI指令文件
AI编程工具会读取项目说明、Agent规则、提示文件、代码注释和任务文档。
攻击者可以在这些内容中写入指令，引导Agent读取文件、执行命令、修改配置或调用外部服务。
仓库里的风险由此分成三类：
- 程序直接执行；
- 开发工具根据配置执行；
- AI Agent理解内容后代为执行。
三、AI编程工具增加了哪些环节
普通代码编辑器提供浏览、编辑、搜索和调试功能。
AI编程Agent还可以：
- 扫描整个仓库；
- 修改多个文件；
- 安装依赖；
- 执行测试；
- 运行Shell命令；
- 调用Git；
- 打开网页；
- 查询文档；
- 启动MCP工具；
- 登录云服务；
- 创建分支和提交；
- 推送代码；
- 发起Pull Request；
- 触发部署流程。
开发人员过去需要逐步完成的操作，现在可以由Agent连续执行。
一段隐藏在README、代码注释、Issue内容或工具返回结果中的恶意指令，可能影响Agent后面的操作。VS Code官方安全文档也明确提醒，文件、工具输出和网页中的内容可能形成提示词注入，诱导Agent执行有害命令或调用外部服务。
Agent自主性越高，攻击链越短。
传统攻击可能需要诱导用户完成以下操作：
1 | 下载项目 → 解压文件 → 打开终端 → 复制命令 → 执行脚本 |
在高权限开发Agent环境中，路径可能缩短为：
1 | 打开项目 → Agent读取内容 → Agent调用工具 → 命令获得执行 |
Cursor的git.exe问题甚至省去了Agent参与。编辑器加载项目本身就可能触发执行。
四、开发电脑里有什么值得攻击
普通员工电脑里可能有办公文件和浏览器账号。
开发人员电脑通常还保存着企业信息系统的钥匙。
常见内容包括：
- GitHub、GitLab和企业代码平台令牌；
- SSH私钥；
- 云平台访问密钥；
- 数据库连接字符串；
.env文件；- npm、PyPI和容器仓库凭据；
- 代码签名证书；
- VPN配置；
- 生产环境跳板机账号；
- 内部API文档；
- 客户项目源代码；
- 本地模型和企业知识库；
- 浏览器登录状态；
- 企业邮件和即时通信账号。
恶意程序获得当前用户权限后，可以尝试读取这些内容。
如果开发人员同时拥有生产部署权限，攻击还可能继续扩展：
1 | 开发电脑 → 代码仓库账号 → 企业私有仓库 → CI/CD系统 → 软件制品 → 客户环境 |
开发终端因此具有软件供应链入口的属性。
攻击者不一定直接攻击生产服务器。控制一名具有发布权限的开发人员，也可能把恶意代码带入正式版本。
五、为什么代码审查挡不住所有恶意仓库
很多人认为，只要先看代码再运行，就可以避免风险。
问题在于，打开项目本身可能已经触发工具行为。
即使编辑器不会自动执行git.exe，仓库中仍可能存在：
- 隐藏文件；
- 超长路径；
- 符号链接；
- 嵌套仓库；
- 大型二进制文件；
- 经过编码的脚本；
- 恶意扩展建议；
- 构建阶段下载的外部程序；
- 依赖包中的安装脚本；
- Agent规则中的隐藏指令。
人工查看几份源代码，很难覆盖整个项目。
静态扫描也存在边界。一个脚本单独看没有问题，配合环境变量、网络访问和云凭据后才产生危害；一段普通说明文字，只有被AI Agent当成指令时才形成攻击路径。
安全措施需要覆盖代码、配置、工具、Agent和执行环境。
六、工作区信任应当放在第一道门
VS Code从2021年开始提供Workspace Trust机制。
未知项目可以在受限模式中打开。受限模式会限制任务、调试、工作区配置以及部分扩展功能。当前的VS Code安全基线还会直接禁用不受信任工作区中的Agent。
这套机制表达了一个简单原则：
打开目录与授予执行权限应当分开。
开发人员可以先浏览源代码，再决定是否信任项目。
企业使用AI编程工具时，还应把几种信任分别管理：
- 是否信任当前工作区；
- 是否信任扩展发布者；
- 是否信任MCP服务器；
- 是否允许Agent访问某个网络域名；
- 是否允许Agent执行终端命令；
- 是否允许修改敏感文件；
- 是否允许向远程仓库推送。
一次点击“信任全部”会把多个边界合并。
项目来源可靠，也不代表项目推荐的扩展、MCP服务器和外部域名都可以获得相同权限。
七、陌生仓库应放进一次性环境
对来源不明的仓库，隔离环境比人工判断更可靠。
可以使用：
- 一次性虚拟机；
- Windows Sandbox；
- 独立测试电脑；
- 无宿主机敏感目录挂载的开发容器；
- 临时云开发环境；
- 专门的恶意代码分析环境。
Mindgard给出的临时建议也是在Windows Sandbox、虚拟机或其他可销毁环境中打开不受信任项目。企业Windows环境还可以使用AppLocker或Windows App Control，禁止工作区目录中的特定可执行文件运行。
隔离环境需要注意几个细节。
1. 不挂载个人主目录
不要把以下目录直接挂进容器或虚拟机：
1 | ~/.ssh ~/.aws ~/.config 浏览器配置目录 企业云盘目录 个人代码目录 |
2. 不直接传入长期凭据
测试陌生项目时，不应自动注入GitHub令牌、云平台密钥、npm令牌和生产数据库账号。
确需访问代码平台时，应使用短期、低权限、单仓库令牌。
3. 限制网络出口
陌生程序即使成功执行，也不应自由连接互联网。
可以默认阻断外网，只允许访问完成任务所需的域名。VS Code的Agent安全机制也支持对沙箱命令设置网络域名过滤。
4. 使用可销毁环境
分析结束后删除整个环境，不继续作为日常开发机使用。
GitHub Codespaces采用独立虚拟机和隔离网络，每个Codespace之间互不共用虚拟机。重新启动时会部署新的虚拟机环境。
云开发环境仍需控制令牌权限、网络出口和端口开放，隔离不能替代权限管理。
八、Agent自动执行需要分级
很多开发人员为了提高效率，会选择：
- 自动批准终端命令；
- 跳过工具确认；
- 允许Agent连续运行；
- 允许自动安装依赖；
- 允许自动提交或推送；
- 开启Autopilot或类似模式。
这些设置适合经过审查的内部项目。
陌生仓库应使用最低自主级别。
可以把操作分成三档。
低风险操作
可以自动执行：
- 读取工作区内文本文件；
- 搜索代码；
- 生成修改建议；
- 创建不覆盖原文件的草稿；
- 运行无网络、无外部写入的静态分析。
中风险操作
逐次确认：
- 安装依赖；
- 执行测试脚本；
- 运行构建命令；
- 修改配置文件；
- 调用MCP工具；
- 访问外部网站；
- 创建Git提交。
高风险操作
必须使用隔离环境，并由人工复核：
- 读取工作区外文件；
- 访问SSH密钥和云凭据；
- 使用管理员权限；
- 推送远程仓库；
- 发布软件包；
- 修改CI/CD配置；
- 调用生产环境；
- 创建云资源；
- 执行部署；
- 修改组织级权限。
VS Code官方建议把自动批准限制在当前会话中，避免将高权限永久授予整个工作区或用户账号。它还建议保护.env等敏感文件，并对文件改动使用差异视图审查。
九、沙箱需要管住文件和网络
确认对话框容易造成疲劳。
开发人员连续批准十几条正常命令后，很可能快速点击下一次确认。
命令解析规则也可能遇到别名、复杂引号、Shell组合语法和子进程调用。仅依靠字符串白名单，难以覆盖所有执行路径。
操作系统级沙箱可以提供更稳定的边界。
一套开发Agent沙箱至少应限制：
文件读取范围
默认只能读取当前工作区。
用户主目录、SSH目录、云平台配置和浏览器资料应处于拒绝范围。
文件写入范围
只允许写入当前项目或临时目录。
禁止修改Shell启动文件、系统目录、其他项目和企业同步盘。
网络访问范围
默认禁止外部连接。
确需下载依赖时，只开放指定软件源。确需调用GitHub时，也要明确该连接具有读权限还是写权限。
允许访问api.github.com，可能同时允许创建分支、发起Pull Request或修改仓库设置。域名白名单不能代替接口和账号权限控制。
子进程继承
Agent启动的Shell、包管理器、编译器和测试程序，都要继承相同限制。
如果子进程能够逃离沙箱，主进程的权限控制便失去意义。
容器边界
需要更强隔离时，可以把Agent和开发工具一起放进开发容器或虚拟机。
宿主机只接收经过审查的代码差异和构建产物。
十、企业可以建立一套陌生仓库处理流程
企业经常接触外部代码：
- 开源项目；
- 客户提供的样例；
- 供应商SDK；
- 应聘者代码；
- 外包团队交付物；
- 安全研究样本；
- 网上下载的Demo；
- AI生成并打包的项目。
这些仓库不宜直接进入员工日常开发电脑。
一套处理流程可以分成六步。
第一步：来源登记
记录仓库地址、提交版本、提供方、下载时间和使用目的。
尽量固定到具体Commit，避免后续代码变化。
第二步：文件清点
检查：
- 根目录可执行文件；
- 脚本文件；
- 隐藏目录；
- Git钩子；
- 嵌套仓库；
- 工作区配置；
- Agent规则；
- MCP配置；
- 构建脚本；
- 依赖安装脚本；
- 二进制文件；
- 符号链接。
发现根目录中的git.exe、node.exe、python.exe等工具同名程序，应直接进入安全审查。
第三步：受限浏览
先在受限模式或纯文本查看器中阅读代码。
不要自动运行任务、调试器、扩展、Agent和安装脚本。
第四步：隔离执行
需要构建、测试或让Agent分析时，放入一次性环境。
环境中不保存个人凭据，不连接生产网络。
第五步：输出审查
检查Agent修改内容、生成文件、依赖变化、网络连接和终端轨迹。
需要导出的代码通过补丁或经过扫描的制品进入正式开发环境。
第六步：销毁环境
任务完成后删除虚拟机、容器、临时令牌和缓存。
十一、CI/CD也要把外部代码当成不可信输入
本地开发机不是唯一风险点。
Pull Request、Issue内容、分支名、提交信息和外部贡献代码，都可能进入自动化流程。
GitHub Security Lab提醒，工作流上下文中的部分数据由攻击者控制。将pull_request_target与外部Pull Request代码检出组合使用，可能导致仓库被控制；引用第三方Action，也意味着把计算资源、令牌和仓库权限交给外部代码。
企业需要检查：
- 外部Pull Request能否接触仓库密钥；
- 测试任务是否使用写权限令牌；
- 工作流是否执行外部贡献者提供的脚本；
- 构建环境是否能够访问内网；
- 发布任务是否与普通测试任务共用凭据；
- Agent能否自行修改工作流并触发执行；
- 自动修复代码是否经过人工审查。
开发Agent提交的代码，也应沿用普通软件供应链控制：
1 | 代码审查 → 静态扫描 → 依赖扫描 → 单元测试 → 沙箱构建 → 制品签名 → 发布审批 |
不能因为代码由内部AI工具生成，就跳过这些环节。
十二、开发环境需要独立安全边界
过去的软件安全工作重点放在应用、服务器、接口和数据库。
AI编程工具把更多能力集中到开发终端：
- 代码读取；
- 文件修改；
- Shell执行；
- Git操作；
- 浏览器访问；
- MCP工具；
- 云平台接口；
- 部署流程。
开发工具获得的权限接近一名熟悉企业系统的工程师。
一个恶意仓库可以同时影响编辑器、Agent、终端、依赖管理器和版本控制系统。任何一个环节自动执行，都可能成为入口。
企业需要把开发环境视为一套单独的信息系统，持续管理：
- 项目信任；
- 工具信任；
- 扩展信任；
- MCP信任；
- 网络信任；
- 凭据权限；
- Agent自主级别；
- 执行环境隔离；
- 操作日志；
- 软件供应链审查。
Cursor的git.exe问题给出了一个很直接的提醒：
代码仓库可以携带代码，也可以携带触发代码执行的条件。
面对陌生项目，安全动作应发生在打开之前。开发人员需要先决定在哪里打开、用什么权限打开、允许哪些工具运行，以及执行失败后会影响哪些系统。
AI编程工具可以帮助开发人员更快理解和修改代码。
它也让一个仓库获得了更多接触终端、凭据、网络和企业系统的机会。
仓库来源越陌生，工具权限越要收紧；Agent自主程度越高，运行环境越要隔离。