AI Security

外观

AI 应用与智能体系统安全 · A5.5 Agent Runtime、Sandbox 与 Workspace更新 2026-08-23约 9 分钟证据：强 来源：GitHub Security Advisory GHSA-wpqr-6v78-jr5g

Gemini CLI 无人值守模式工作区信任绕过 RCE（CVSS 10.0） ​

摘要 ​

Google 官方安全公告 GHSA-wpqr-6v78-jr5g 披露：Gemini CLI（@google/gemini-cli 0.39.1 以下版本及 0.40.0-preview.2）与配套的 google-github-actions/run-gemini-cli（0.1.22 以下版本）有两个复合设计缺陷，组合后构成 CVSS 10.0（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）的远程代码执行漏洞。第一个缺陷是：在 CI/CD 等无人值守（headless）模式下运行时，Gemini CLI 会自动信任当前工作区目录，不经审查、不经沙箱初始化、不经人工批准就加载该目录下的 Agent 配置（.gemini/ 目录），使其中的恶意环境变量在沙箱建立之前就以宿主权限执行。第二个缺陷是：--yolo 模式下，细粒度工具白名单被忽略，使提示词注入可以直接触发任意 shell 命令执行。

Novee Security 的 Elad Meged 和 Pillar Security 研究团队的 Dan Lisichkin 通过 Google 漏洞奖励计划分别报告了该漏洞，Google 已在 2026-04-24 发布公告并同步修复（@google/gemini-cli 0.39.1、0.40.0-preview.3；run-gemini-cli 0.1.22）。

核心创新与差异 ​

原研究贡献：Google 官方公告首次系统说明 Gemini CLI 在交互模式与无人值守模式下的信任模型差异，并明确两个独立缺陷如何复合：一个绕过了"是否加载配置"的前置信任检查，另一个绕过了"配置加载后能做什么"的后置权限检查，二者叠加使得整条链路可以在模型未做出任何推理决策之前就完成代码执行。

本站分析认为，这起漏洞的首个失效控制是工作区信任边界（workspace-to-execution），而不是内容到指令边界（content-to-instruction）：第一个缺陷（无人值守模式自动信任工作区）完全不需要提示词注入或模型推理参与，攻击者放在仓库里的恶意配置在 Agent"思考"之前就已经执行——这与本站已收录的 Windows 二进制搜索顺序劫持、AWS Kiro 配置投毒（见AI CLI 工具的零点击 RCE）属于同一类"沙箱/工作区信任交接"失效模式，但触发场景更窄（限定无人值守/CI 模式）、根因更接近默认信任配置本身，而非路径解析或文件写入审批缺失。第二个缺陷（--yolo 模式下工具白名单被忽略）则是提示词注入与权限控制失效的复合，说明同一产品可以在不同运行模式下暴露不同层级的失效控制。

威胁模型与攻击链 ​

攻击者不需要控制受害者设备，也不需要说服受害者点击任何链接；只需要能够把内容放进受害者会用 Gemini CLI（尤其是通过 run-gemini-cli GitHub Action）处理的代码仓库，例如通过 Pull Request、fork 后的分支或依赖文件。

缺陷一：无人值守模式的工作区自动信任 ​

  1. 攻击者向目标仓库提交一个包含恶意 .gemini/ 配置（例如恶意环境变量定义）的 Pull Request 或分支。
  2. 目标仓库的 CI/CD 流水线（如 GitHub Actions）以无人值守/headless 模式调用 Gemini CLI 处理该分支或 PR。
  3. Gemini CLI 在该模式下默认信任当前工作区目录，不经过交互模式下才有的信任提示，直接加载 .gemini/ 目录中的配置。
  4. 配置中的恶意环境变量就在沙箱初始化之前，以运行 CI 任务的宿主权限被执行——全程不涉及模型推理或决策，纯粹是基础设施层面的执行。

缺陷二：--yolo 模式下的工具白名单绕过 ​

  1. Gemini CLI 以 --yolo 参数运行时，本应限制可调用工具范围的细粒度白名单被忽略。
  2. 不可信输入（如仓库内容中的提示词注入）诱导模型决定调用任意 shell 命令。
  3. 因白名单未被强制执行，该命令未经额外确认即被执行。

Google 官方公告将修复描述为"强化工作区信任与工具白名单机制，特别是在 GitHub Actions 等不可信环境中使用时"，并说明该修复会给无人值守环境下的目录信任处理带来不兼容变更（breaking change）。

后续事件：恶意 Issue 到 GCP 项目权限 ​

Pillar Security 在 2026 年 8 月披露了同一控制链的后续实例。Gemini CLI 仓库的自动分诊工作流会以 --yolo 处理公开 GitHub Issue；工作流仍传入旧的顶层 coreTools，而当时的 CLI 0.46.0 只读取 tools.core 或 tools.allowed。该配置因此被静默丢弃，策略引擎回落到通配符允许规则，提示词注入可调用不在预期范围内的 run_shell_command。

研究人员随后读取 Runner 上由 Workload Identity Federation 写入的明文凭据文件，并利用项目级 roles/iam.serviceAccountTokenCreator 模拟其他服务账号，最终取得测试项目中的 Editor 权限。Google 说明该项目是 Gemini CLI 自动分诊专用沙箱；这不改变链路所暴露的工程问题：不可信 Issue、失效的工具范围配置、可读云凭据和过宽身份模拟权限被串成了一个跨层攻击路径。Google 修正了工具范围配置，将凭据文件加入 .geminiignore，并把身份模拟权限缩小到单个服务账号资源。

攻击工件与复现材料 ​

来源为官方安全公告，未公开可直接复用的完整 PoC 或利用脚本；本文不重构可用于真实系统的payload，只给出判定信号。

text
缺陷一判定信号：
  - Gemini CLI 运行模式为无人值守/headless（典型场景：GitHub Actions 中的 run-gemini-cli）
  - 工作区目录下存在 .gemini/ 配置，且该目录内容来自不受信任的分支/PR
  - 配置加载发生在沙箱初始化之前，且未触发任何用户确认

缺陷二判定信号：
  - Gemini CLI 以 --yolo 参数运行
  - 模型处理的输入包含来自不可信来源的内容（仓库文件、Issue、PR 描述等）
  - 模型据此调用的 shell 命令未经细粒度工具白名单校验即执行

受影响版本与修复版本（官方公告）：

text
@google/gemini-cli          < 0.39.1                          -> 已修复：0.39.1、0.40.0-preview.3
@google/gemini-cli           = 0.40.0-preview.2                -> 已修复：0.40.0-preview.3
google-github-actions/run-gemini-cli  < 0.1.22                 -> 已修复：0.1.22

实验设计与实际过程 ​

以下为 Google 官方安全公告披露的漏洞报告与修复记录，本站未独立复现。漏洞由两名独立研究者（Novee Security 的 Elad Meged、Pillar Security 研究团队的 Dan Lisichkin）分别通过 Google 漏洞奖励计划报告；公告于 2026-04-24 发布，2026-04-25 更新。

关键结果与实际影响 ​

官方给出的 CVSS 评分为 10.0（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H）——网络可达、低复杂度、无需权限、无需用户交互、影响范围跨越安全边界（Scope: Changed）、机密性/完整性/可用性均为高。影响限定于以无人值守模式运行 Gemini CLI 的工作流（典型是 CI/CD 集成），交互模式下受信任提示仍然存在，不受此特定链路影响。两个漏洞均已在指定版本修复；未升级到修复版本的用户在无人值守场景下仍可能暴露。

防护措施与验证方法 ​

  • 将 @google/gemini-cli 升级至 0.39.1 或 0.40.0-preview.3 及以上，将 google-github-actions/run-gemini-cli 升级至 0.1.22 及以上。
  • 在 CI/CD 等无人值守环境中使用 Gemini CLI 时，显式配置工作区信任策略，不依赖默认自动信任；对不可信分支/PR 触发的工作流应使用最小权限的隔离执行环境。
  • 避免在处理不可信仓库内容的流水线中使用 --yolo 模式；如必须使用，需确认细粒度工具白名单在该模式下被强制执行（依据已修复版本的行为）。
  • 将 .gemini/ 等 Agent 配置目录纳入代码审查范围，视同可执行制品而非普通配置文件，尤其是来自 Fork 或外部贡献者分支的变更。
  • 对配置字段实施严格 schema 校验：已弃用、拼写错误或位置错误的工具范围字段必须让工作流失败，不能静默回落为通配符允许；在集成测试中断言危险工具确实被拒绝。
  • 不把 Runner 上的 OIDC/WIF 凭据文件视为“只有受信进程才能读取”；Agent 能读文件或执行命令时，应隔离凭据、限制其有效期与 audience，并把 serviceAccountTokenCreator 绑定到明确的目标服务账号。
  • 验证升级后的行为变化：官方说明该修复对无人值守环境下的目录信任处理是不兼容变更，升级后应重新测试 CI/CD 流水线中 Gemini CLI 的信任配置是否仍按预期工作，而不是假设修复后行为不变。

局限与待验证问题 ​

  • 证据等级为强：来源是厂商官方安全公告，含明确的 CVSS 向量、受影响/修复版本和研究者署名，但公告未公开完整 PoC 或利用脚本，本站未独立复现攻击链。
  • 两个复合缺陷各自的独立利用条件（例如缺陷一是否必须结合无人值守模式，缺陷二在非 --yolo 模式下是否仍有残余风险）官方公告未逐一区分，本文按公告原文的复合描述呈现，不做超出原文的拆分推测。
  • 未说明该漏洞在真实生产 CI/CD 环境中的实际影响范围或是否存在在野利用；两名研究者均通过负责任的漏洞奖励计划渠道报告，未见独立第三方复现记录。
  • 修复引入的不兼容变更具体影响哪些既有工作流配置，官方公告未详细列出，需要使用方自行验证升级后行为。
  • A WIF 事件的端到端证据来自发现方在 Google 专用沙箱中的演示，不能据此推断所有采用 run-gemini-cli 的组织都暴露；实际风险取决于工作流是否处理不可信内容、CLI/Action 版本、工具配置、凭据可见性和 IAM 范围。

参考链接 ​