谷歌近日发布安全公告，确认已修复 Gemini CLI 中存在的一处高危漏洞。这个问题波及 npm 包 @google/gemini-cli 以及 GitHub Action google-github-actions/run-gemini-cli，一旦在 CI/CD 等自动化场景中触发，攻击者便有可能执行远程代码，直接威胁整个开发环境的安全。

漏洞并非单一缺陷，而是两个弱点叠加

这次的安全问题并不是某个孤立的代码错误，而是两个相关缺陷相互作用的结果：一是无头环境下对工作区信任的处理过于宽松，二是 --yolo 模式下工具白名单机制存在绕过可能。两者叠加，让处理外部用户提交内容（比如开源项目的 PR 或 Issue）的系统暴露在风险之中。

问题一：无头模式下自动信任工作区

Gemini CLI 在设计之初为了方便自动化使用，在非交互式环境中会默认信任当前工作目录。这意味着 CLI 启动后，无需任何人工确认就能直接读取 .gemini/ 目录下的本地配置文件和环境变量。

这个设计在内部可控环境中问题不大，但一旦 CI 流水线处理的是不受信任的代码仓库，攻击者只需在 .gemini/ 目录中植入恶意配置，CLI 就会乖乖加载并执行其中的有害指令。换句话说，任何处理外部贡献者代码的 GitHub Actions 工作流，都可能成为远程代码执行的入口。

问题二：--yolo 模式放宽了工具限制

第二个隐患藏在 --yolo 参数里。开启该模式后，早期版本并未严格执行 ~/.gemini/settings.json 中设定的细粒度工具权限。举个例子，如果管理员只打算开放 run_shell_command 中的某几条安全命令，实际运行时策略却可能大幅放宽，让危险操作也得以通过。

在存在提示注入（Prompt Injection）风险的场景下，攻击者完全可以通过精心构造的输入文本，诱导 Gemini CLI 执行超出授权范围的 shell 命令。这种"借刀杀人"的手法，对自动化工作流尤其致命。

影响范围：无头部署是重灾区

谷歌在公告中明确，漏洞的影响集中在无头模式下的 Gemini CLI 部署。虽然范围看似有限，但要知道，大量团队正是通过 GitHub Actions 调用 Gemini CLI 来实现代码审查、文档生成或自动化测试的。一旦这些流水线对外部贡献者开放，风险便会被迅速放大。

谷歌建议所有使用自动化流水线的团队立即自查，重点排查以下场景：

• 工作流是否处理来自外部用户的文件、提示词或环境变量

• Gemini CLI 是否以无头模式运行

• 是否启用了 --yolo 参数且未严格限制工具权限

修复方案：升级版本 + 调整信任策略

目前官方已发布补丁，用户应尽快完成升级：

• npm 包 @google/gemini-cli 需更新至最新修复版本

• run-gemini-cli GitHub Action 已在对应版本中修复

除了打补丁，谷歌还做了一项重要的安全策略调整：无头模式将不再默认信任工作区文件夹。以后如果确实需要让 CLI 信任当前目录，必须在环境变量中显式设置 GEMINI_TRUST_WORKSPACE: 'true'。对于处理不可信输入的工作流，谷歌提供了专门的加固指南，要求管理员逐条审查允许的工具列表和命令执行范围。

漏洞披露背后的警示

这处漏洞由 Novee Security 的 Elad Meged 和 Pillar Security 的 Dan Lisichkin 通过谷歌漏洞奖励计划上报。事件本身给整个行业敲响了警钟：AI 驱动的开发者工具正在深度融入工程流水线，当自动化执行、自然语言提示和系统级 shell 访问三者交汇时，哪怕是一个微小的策略缺口，也可能被攻击者利用，演变成关键的入侵路径。

对于正在使用 Gemini CLI 的团队来说，这次修复不仅是更新一个 npm 包那么简单，更是一次重新审视 CI/CD 安全边界的机会。在 AI 工具越来越"聪明"的今天，给它们划定清晰的操作权限，或许比让它们跑得更快更重要。