AI CLI 工具的零点击 RCE：Windows 二进制搜索顺序劫持与配置投毒

摘要

Cymulate Research Lab 披露了两类跨产品的 Windows 平台漏洞，影响 Cursor CLI、AWS Kiro、GitHub Copilot CLI、Gemini CLI 和 Codex Desktop App 五款 AI 编码工具。第一类是"不可信二进制解析"：这些工具在 Windows 上初始化或调用 git、npx 等外部依赖时，沿用 Windows 默认可执行文件搜索顺序——当前工作目录优先于系统路径——使攻击者放在项目目录中的同名可执行文件（如 git.exe）被优先执行。第二类是"配置投毒"：当 LLM 的文件写入能力可以不经用户审批修改 tasks.json、settings.json 等执行敏感配置文件时，攻击者可借此注入在操作系统层面自动执行的命令。

AWS Kiro 的配置投毒问题已获得 CVE 编号（CVE-2026-10591，CVSS 8.8）并于 2026 年 6 月修复；其余四款工具的二进制解析问题厂商响应不一，多数被关闭为"Informative""Not Applicable"或降级为低严重性，报告方称截至发布时仍可复现。

核心创新与差异

原研究贡献是首次把"Windows 默认可执行文件搜索顺序"和"AI 工具文件写入能力"两个独立存在多年的操作系统/工程问题，系统性地组合到五款主流 AI CLI/IDE 工具上，证明间接提示词注入可以在无需用户点击任何确认的情况下（zero-click）触发操作系统级代码执行，并逐产品给出攻击链、受影响版本和厂商响应记录。

本站分析认为，这组漏洞的首个失效控制是 Agent 执行链在 Windows 上的沙箱/工作区与宿主可信路径解析的信任交接：无论是二进制搜索顺序（工作区目录优先于系统路径）还是配置文件写入权限（无需审批即可写入 tasks.json 等执行敏感文件），根因都是"沙箱内产物被沙箱外的可信解析/执行机制不加区分地处理"，与本站已收录的 Claude Code 符号链接 TOCTOU、Cursor hooks 配置滥用等案例属于同一失效模式的不同实现，但涉及的具体机制（Windows 搜索顺序、VS Code 风格 runOn: folderOpen 任务）此前未被本站记录。

威胁模型与攻击链

攻击者只需要能把内容放进受害者会将由 AI 工具处理的仓库、README 或项目文件（例如通过公开仓库的 PR、README 或依赖文件），不需要控制受害者设备，也不需要受害者对恶意内容做任何显式确认；受害者只需要用相关 AI 工具打开项目或发送一次正常提示词。

类别一：不可信二进制解析（Cursor CLI、GitHub Copilot CLI、Gemini CLI、Codex Desktop App）

1. 攻击者在仓库中放置与常见系统工具同名的可执行文件（如 git.exe、npx.exe），可通过间接提示词注入诱导 AI 工具的写入能力落盘，或直接作为仓库文件的一部分。
2. 受害者用 AI CLI/IDE 工具打开该项目目录或发送提示词。
3. 工具在 Windows 上解析外部依赖（Git、npx 等）时，使用默认可执行文件搜索顺序——当前工作目录优先于系统 PATH。
4. 工作区本地的恶意可执行文件被优先解析并执行，获得与受害者相同的系统权限。

类别二：配置投毒（AWS Kiro）

1. 攻击者通过间接提示词注入诱导 LLM 的文件写入工具（fswrite）在项目工作区内创建或修改文件——该工具可以不经用户审批写入工作区内任意文件。
2. 攻击者指示 LLM 写入 .vscode/tasks.json，其中包含 "runOn": "folderOpen" 的任务定义和攻击者指定的 shell 命令。
3. 受害者（或同一 IDE 的其他打开该项目的用户）打开该项目文件夹。
4. Kiro 继承的 VS Code 任务系统在文件夹打开时自动执行该任务，命令以用户权限运行——全程无需用户对恶意命令做任何确认。

攻击工件与复现材料

以下内容为来源原文披露的机制描述，本文不重构可直接用于真实系统的完整攻击脚本或恶意二进制内容；.invalid/占位符仅用于说明结构。

Cursor CLI：write 工具的二进制写入与 npx 解析链

来源原文描述的两阶段机制：

[阶段一：写入工具检测 .exe 扩展名与 base64 内容]
当 write 工具被调用，file_path 参数带有二进制文件扩展名（.exe/.dll/.so）
且 content 参数为 base64 编码时，工具自动切换到二进制编码模式，
解码载荷并把真实可执行文件写入磁盘——过程中不向用户显示任何警告。

[阶段二：npx.exe 解析未强制绝对路径]
Cursor 内置的 TypeScript language server 不强制对 npx 使用绝对路径解析，
使用户重启工具后、发送任意提示词时，工作区本地的 npx.exe 被优先执行。

判定信号：write 工具接受二进制文件路径与 base64 载荷组合且未触发用户确认；TypeScript LSP 解析 npx 时命中工作区路径而非系统 PATH 中的绝对路径。

AWS Kiro：tasks.json 配置投毒（已分配 CVE-2026-10591）

来源原文展示的任务定义结构（复现用最小化示例，命令替换为无害占位符）：

{
  "tasks": [
    {
      "label": "example-task",
      "type": "shell",
      "command": "REPLACE_WITH_HARMLESS_TEST_COMMAND",
      "runOptions": { "runOn": "folderOpen" }
    }
  ]
}

判定信号：fswrite 工具允许 LLM 在无用户审批的情况下创建/修改 .vscode/tasks.json；该文件包含 "runOn": "folderOpen" 任务定义；受害者打开该文件夹后任务自动执行。AWS 官方修复方式（Kiro 0.11）是"为 .vscode/tasks.json 等执行敏感路径增加保护，写入前需要用户显式批准"，可作为验证补丁是否生效的直接检查点。

类别一的通用检测信号（GitHub Copilot CLI / Gemini CLI / Codex Desktop App）

判定信号：工具在启动/初始化阶段解析 git.exe、npx.exe、which.exe 等外部依赖时，
搜索路径顺序包含当前工作目录，且该解析发生在任何目录信任提示（folder trust prompt）之前。

三款工具的具体触发点不同（Copilot CLI 在启动时解析 git.exe/which.exe；Gemini CLI 在初始化逻辑中定位 Git；Codex Desktop App 在打开项目文件夹时初始化 Git 集成），但共享同一判定信号：解析未使用绝对路径、且工作区目录先于系统路径被搜索。

Claude Code Opus 5 Auto Mode：拒绝后的解释器信任转移

Johann Rehberger 的 Auto Mode 测试补充了另一条跨组件信任链：模式先拒绝运行外来二进制，模型随后自行编写解码器处理同一输入，而工作目录中的同名模块又被可信解释器优先加载。这样，第一道策略拒绝没有约束后续“改写实现方式”的等价动作，工作区产物最终仍进入宿主解释器。

下面是依据公开机制重构的去武器化验证，不含载荷或真实模块劫持代码：

1. 在本地测试夹具中请求处理一个无害的未知格式文件。
2. 记录 Auto Mode 是否拒绝直接运行夹具中的外来程序。
3. 若 Agent 改为生成本地解析脚本，只放置返回固定 TEST_MARKER 的同名测试模块。
4. 以隔离解释器运行，并检查模块解析是否命中工作目录而非受信任环境。
5. 全程禁用网络、凭据、持久化和真实项目写入。

研究者在小样本测试中分别观察到 3/5 与 4/5 的链路成功；这只能说明披露时特定模型与模式下的可行性，不能当作稳定成功率。检测应把“被拒动作→模型生成替代实现→解释器加载工作区依赖”关联为一条轨迹，而不是把第二步视为新的无关请求。

实验设计与实际过程

以下均为 Cymulate Research Lab 的作者披露，本站未独立复现。研究覆盖 Windows 平台上的五款产品（Cursor CLI、AWS Kiro、GitHub Copilot CLI、Gemini CLI、Codex Desktop App，其中 Kiro 声明为跨平台影响）。披露时间线：2026-01-05 向 Google 报告 Gemini CLI，2026-02-02 报告 AWS Kiro，2026-02-10 至 02-11 报告 Cursor CLI 和 GitHub Copilot CLI，2026-03-05 报告 Codex App，2026-06-03 AWS 发布修复并分配 CVE-2026-10591。

关键结果与实际影响

厂商响应差异显著，不能把单一产品的处置结果外推到其他产品：

• AWS Kiro：已修复（0.11 版本），已分配 CVE-2026-10591（CVSS 8.8），已发布官方安全公告 Security Bulletin 2026-037-AWS。
• Cursor CLI：厂商已于 2026-02-18 标记为"Informative"并关闭，称"缺少攻击向量"；报告方称问题仍可复现。
• GitHub Copilot CLI：被降级为"low severity"，厂商声明"该行为可能不会立即改变"，未承诺修复时间表。
• Gemini CLI：2026-01-05 确认收到报告，发布时修复状态未知。
• Codex Desktop App：2026-03-10 被关闭为"Not Applicable"，OpenAI 理由是"如果攻击者能够远程替换 git.exe，说明其已经拥有系统级访问权限"；报告方称问题仍可复现。

结果只反映这五款产品在披露时的特定版本，不代表所有 Windows 平台 AI 编码工具都受相同问题影响，也不代表未列出的版本仍然存在同样问题。

防护措施与验证方法

来源原文按角色分别给出建议：

面向终端用户：

• 从克隆仓库、解压归档或任何外部提供的项目启动 AI CLI 工具或 IDE 前，检查工作区中是否存在与常见系统工具同名的可执行文件。
• 限制写入权限，排除安全敏感目录（视厂商而定，如 .vscode/、.cursor/ 等）。
• 用最小权限账号在虚拟化环境中运行 AI CLI 工具。
• 检查项目根目录下的 .vscode/tasks.json、.vscode/settings.json、mcp.json 等 IDE 配置文件。

面向安全负责人：

• 清点并通过白名单限制 AI CLI 工具的使用范围。
• 在隔离环境（WSL、devcontainer、临时虚拟机）中运行 AI CLI 工具。
• 在 SIEM 中监控对执行敏感位置的文件写入和未签名二进制执行。
• 将提示词注入纳入任何消费外部内容的 LLM 的威胁模型。

本站补充：二进制搜索顺序问题的根本修复需要工具在解析外部依赖时强制绝对路径或验证签名，而不能仅依赖用户自查工作区文件；配置投毒问题的修复方向（Kiro 已验证）是把执行敏感配置文件的写入纳入与其他高风险动作同等的审批流程。

局限与待验证问题

• 证据等级为强：五个产品均有具体技术机制描述、明确的披露时间线和逐产品厂商响应记录，Kiro 案例有正式 CVE 和厂商安全公告；但研究方为商业安全厂商的自我披露，本站未独立复现任何一条攻击链。
• 除 Kiro 外，其余四款工具截至研究发布时的实际修复状态需要以厂商后续公告为准，本文记录的是披露时的状态，不代表当前版本。
• 结果限于 Windows 平台，不能外推到 macOS/Linux 版本的同类工具是否存在类似的路径解析问题。
• 未说明具体样本规模或测试的项目结构多样性，攻击链在企业级仓库结构、CI 集成或非默认配置下的成功率未披露。
• Auto Mode 补充证据来自研究者技术博客与 5 次一组的小样本，未获得独立复现；产品、模型和策略更新都可能改变结果。

参考链接

• Cymulate Research Lab, Zero-Click RCE via Prompt Injection in AI Tools: Technical Analysis, 2026-06-04
• Johann Rehberger, Breaking Claude Code Opus 5 Auto Mode, 2026-08