漏洞概述与影响范围

2026年4月，Google 旗下 Gemini CLI 工具被曝出存在严重安全缺陷，编号 CVE-2026-12537，该漏洞在特定 CI/CD 环境下可被利用执行任意代码，对自动化构建流程构成直接威胁。受影响范围涵盖 @google/gemini-cli npm 包 0.39.1 之前版本、0.40.0-preview.3 之前预览版，以及 google-github-actions/run-gemini-cli GitHub Action 0.1.22 之前的所有版本。

这一漏洞由 Novee Security 与 Pillar Security 研究团队联合发现并负责任披露，Google 方面已在 2026 年 4 月 24 日发布安全公告 GHSA-wpqr-6v78-jr5g 予以确认。CVSS 评分达到最高等级 10.0 分，意味着攻击者无需任何特权或用户交互即可通过网络发起低复杂度攻击，成功利用后可能导致机密性、完整性与可用性的全面丧失。

无头模式下的信任危机

问题的核心出在 Gemini CLI 处理"无头"环境的方式上。所谓无头模式，即 CLI 在自动化 CI 流水线中运行时所处的非交互状态。在此模式下，早期版本的 Gemini CLI 会自动信任当前工作区文件夹，直接加载其中存储的配置文件与环境变量。

具体而言，仓库根目录下的 .gemini/.env 文件会被静默读取并应用。攻击者只需向目标仓库提交一个包含恶意环境变量的拉取请求，当 CI 工作流触发并调用存在漏洞的 Gemini CLI 时，这些变量便会被自动加载。由于这一过程发生在沙箱初始化之前，恶意命令得以在主机层面直接执行，完全绕过了预期的安全隔离机制。

这种设计上的疏忽在交互式使用中或许不易察觉——毕竟本地开发者面对信任弹窗时通常会选择确认——但在自动化流水线中，没有人机交互环节，隐式信任便转化为实实在在的安全缺口。任何能够影响仓库内容的外部贡献者，都可以借此在构建服务器上植入并执行任意代码。

--yolo 模式下的工具管控失效

除工作区信任问题外，另一个独立但同样危险的缺陷涉及 --yolo 运行模式。在该模式下，Gemini CLI 会跳过对工具的逐条审批，这本是为了提升自动化效率而设计的便利功能。然而旧版本在处理这一模式时存在一个关键疏漏：细粒度的工具允许列表被完全忽略。

正常情况下，管理员可以在配置中限定 Gemini CLI 只能调用特定工具，例如仅允许执行 echo 命令。但在 --yolo 模式下，这一限制形同虚设，任何 shell 命令都可以被直接执行。当工作流处理来自不可信来源的输入时，攻击者通过提示注入技术即可诱导 AI 代理运行未经授权的指令。

这一漏洞与第一个问题叠加后，攻击面被显著放大。攻击者不仅可以通过环境变量注入实现主机级代码执行，还能借助提示注入操控 AI 代理的行为，使其在自动化流程中执行更具破坏性的操作，例如窃取构建环境中的密钥凭证、篡改构建产物，甚至向主分支推送恶意代码。

真实攻击场景推演

设想一个典型的开源项目维护场景。某仓库配置了 Gemini CLI 用于自动处理 issue 分类与 PR 审查，工作流在公共 issue 被创建或评论时自动触发。攻击者创建一个 issue，在标题或正文中嵌入精心构造的提示注入内容，同时提交一个包含恶意 .gemini/.env 文件的拉取请求。

当维护者的 CI 流水线运行存在漏洞的 Gemini CLI 版本时，首先会加载 .gemini/.env 中的恶意环境变量，触发预设命令的执行。由于此时沙箱尚未启动，这些命令在主机上拥有完整权限。攻击者可以借此读取工作流中的 GITHUB_TOKEN、云服务商凭证、npm 发布令牌等敏感信息。

获取高权限令牌后，攻击者进一步横向移动，获得仓库的完整写入权限。这意味着他可以直接向主分支推送经过篡改的代码，这些代码会随正常发布流程分发给所有下游用户，形成典型的供应链攻击闭环。Pillar Security 的研究表明，至少有八个其他 Google 仓库使用了相同的脆弱工作流模板，攻击面远超单一项目。

官方修复与版本升级

Google 在收到披露后迅速响应，于 2026 年 4 月 24 日推送了修复版本。核心改动围绕两个方向展开：

工作区信任机制重构：新版 Gemini CLI 在无头模式下不再自动信任任何工作区，而是要求管理员显式声明信任关系。只有通过 GEMINI_CLI_TRUST_WORKSPACE=true 环境变量明确标记后，配置文件与 .env 文件才会被加载。这一改动使无头模式的行为与交互模式保持一致，消除了隐式信任带来的安全隐患。

--yolo 模式下的工具白名单强制生效：即使在自动审批模式下，工具允许列表现在也会被严格执行。管理员配置的 allowed-tools 限制不再被绕过，shell 命令的执行范围被严格限定在预设清单内。

受影响用户应立即执行以下升级操作：将 @google/gemini-cli 升级至 0.39.1 稳定版或 0.40.0-preview.3 预览版；将 google-github-actions/run-gemini-cli GitHub Action 升级至 0.1.22 或更高版本。升级后需重新测试工作流，因为信任行为的变更可能影响原有配置文件的加载逻辑。

防御加固建议

单纯升级版本并不足以消除所有风险，团队还需从架构层面审视 AI 代理在 CI/CD 环境中的部署方式。以下是经过实践验证的加固策略：

输入分级处理：明确区分可信与不可信输入源。来自公共 issue、fork PR、外部评论的内容应被视为潜在恶意数据，处理这些输入的工作流不应拥有写入权限或访问敏感密钥。

最小权限原则：为工作流配置尽可能精简的 GitHub Token 权限。默认采用只读权限，仅在确有必要时才在最小范围的 job 中授予写入权限。避免在不可信输入处理 job 中暴露云凭证、发布令牌等高价值密钥。

工具调用限制：为处理不可信输入的工作流禁用 run_shell_command 等通用执行工具，仅保留 list_directory、read_file、grep_search 等只读分析工具。若必须使用 shell 命令，应采用命令级白名单并配合沙箱环境。

人工审批机制：对于涉及公共不可信内容的自动化流程，建议改为由维护者手动触发，而非在 issue 创建或 PR 提交时自动执行。这种设计虽然降低了响应速度，但显著提升了安全边界。

环境隔离：处理不可信输入的 job 应运行在临时构建环境中，避免使用长期存在的自托管 runner。临时环境在任务结束后即被销毁，即使遭受攻击也能将影响控制在单次运行范围内。

行业启示与深层反思

Gemini CLI 这起漏洞并非孤例，它折射出 AI 编码代理融入开发流水线后带来的新型安全挑战。传统 CI/CD 安全模型假设自动化脚本是确定性的，而 AI 代理的核心特性恰恰是不确定性——它会根据自然语言输入动态决定调用哪些工具、执行什么操作。当这种不确定性遇上具有执行权限的自动化环境，安全边界便变得模糊而脆弱。

近两年的供应链攻击态势持续升级：2024 年的 XZ Utils 后门事件展示了如何通过渗透开发工具链实现大规模影响；2025 年的 Shai-Hulud 蠕虫在 npm 生态中自我传播；2026 年初 axios 包被劫持导致数百万次恶意安装。这些案例共同指向一个事实：开发流水线中的任何组件一旦被攻陷，其影响都会通过依赖关系迅速扩散至下游。

AI 代理作为开发流水线的新兴组件，继承了这种"信任放大器"的特性。它拥有读取仓库内容、调用系统工具、访问密钥凭证的能力，同时又暴露于来自公共 issue、PR 评论等不可信输入源。这种"高权限 + 不可信输入"的组合，正是攻击者梦寐以求的突破口。

安全团队需要将 AI 代理视为一种特殊的自动化主体来管理，而非单纯的聊天界面。这意味着要为其建立独立的权限边界、工具白名单、输入验证层和审计日志。当不可信文本能够影响 AI 代理的行为时，必须假设最坏情况已经发生，并确保即使代理被操控，其所能造成的破坏也被严格限制在可控范围内。

结语

CVE-2026-12537 的披露为所有在 CI/CD 环境中部署 AI 编码代理的团队敲响了警钟。漏洞本身的技术原理并不复杂——工作区隐式信任与工具管控失效——但其在自动化场景中的实际影响却极为严重。从环境变量注入到主机级代码执行，从密钥窃取到供应链污染，攻击链条清晰而完整。

Google 已提供修复版本，但真正的安全提升来自于组织层面的防御意识升级。将 AI 代理纳入特权自动化主体的管理范畴，实施输入分级、最小权限、工具限制、环境隔离和人工审批等多重控制，才能在享受 AI 带来的效率提升的同时，守住安全底线。对于仍在使用受影响版本的用户，升级不应再被拖延——在供应链攻击日益频繁的今天，每一个未修补的漏洞都是潜在的入口。