Google Gemini CLI 漏洞允许攻击者在主机系统上执行命令

2026-05-01 00:00:54 1 50

Google Gemini CLI 及其关联的 GitHub Action 中存在一个严重的远程代码执行漏洞。该漏洞的 CVSS 严重性评分为 10.0,最高级别为 10.0。该漏洞允许非特权外部攻击者直接在主机系统上执行命令。


Google Gemini CLI 及其关联的 GitHub Action 中存在一个严重的远程代码执行漏洞。该漏洞的 CVSS 严重性评分为 10.0,最高级别为 10.0。该漏洞允许非特权外部攻击者直接在主机系统上执行命令。

这一漏洞实际上将自动化 CI /CD 管道变成了供应链中的潜在攻击途径。

与典型的 AI 漏洞利用不同,这种漏洞利用并不依赖于即时注入或模型操纵。

相反,这是一个基础设施级别的漏洞,在 AI 代理的沙箱甚至还没来得及初始化之前就被触发了。

Google Gemini CLI 漏洞


核心问题是 Gemini CLI 如何处理非交互式环境中的工作区信任。

在 CI/CD 作业期间以无头模式运行时,CLI 会自动信任当前工作区文件夹。

它无需人工批准、安全审查或沙箱即可加载该目录中找到的任何代理配置。

攻击者可以通过发起标准的拉取请求,轻松地在代码仓库的工作区中植入恶意配置文件。

Gemini 代理会默默地信任此文件,从而导致运行工作流的主机上立即执行代码。

这种主机级执行方式允许非特权外部人员访问工作流可以访问的任何密钥、云凭证和源代码。

这种级别的访问权限足以促成代币盗窃 、供应链转移以及向下游生产环境的横向移动。

谷歌已发布安全补丁来修复这一严重漏洞。管理员必须立即升级其环境以防止漏洞被利用。

以下已修复的版本解决了未经身份验证的执行漏洞:

  • 将 google/gemini-cli 更新到版本 0.39.1 or 0.40.0-preview.3.
  • 将 google-github-actions/run-gemini-cli 更新到版本 0.1.22.
  • 根据 Novee Research 的研究 ,AI 编码代理通常在开发流程中运行,并拥有与受信任的人类贡献者相同的执行权限。

这种深度融合意味着人工智能基础设施的漏洞会对供应链构成巨大风险。

Gemini CLI 的缺陷表明, 现代 AI 安全必须保护从模型到应用程序的整个路径,包括 shell 工具、存储库文件和部署工作流程。

威胁行为者越来越多地将目标对准开发流程,以便大规模地向下游用户分发恶意载荷。

近期发生的几起引人注目的软件供应链事件凸显了这一加速趋势:

  • 2026 年 3 月,一个被劫持的维护者帐户导致数百万个 axios npm 包安装受到影响。
  • Shai-Hulud 蠕虫在 2025 年攻击了数百个 npm 包,在其 v2.0 版本中部署了数据擦除器。
  • 2024 年,攻击者通过 OpenSSH 在受影响的 Linux 系统上的 XZ Utils 中植入了远程代码执行后门。
  • 2024 年 Polyfill.io CDN 劫持事件迫使被采用的脚本自动下载恶意代码。

关于作者

weak_hong40篇文章52篇回复

评论1次

要评论?请先  登录  或  注册
  • 1楼
    5 小时前

    这个漏洞本质上是信任链滥用,跟之前xz-utils那个后门思路有点像——都是往合法流程里塞私货。区别是这个不用篡改二进制,直接污染配置就行,门槛低多了。

    利用路径其实很直接:

    1. 找个开放PR的仓库,或者自己新建一个
    2. .gemini/或工作区塞个恶意配置文件(agent.json之类)
    3. 等CI触发,Gemini CLI无头模式直接加载执行
    4. 拿到的权限跟开发者一样,密钥、云凭证全暴露

    这玩意儿最骚的是不需要受害者交互,不需要什么复杂的prompt注入,就正常跑CI就中招了。攻击者甚至可以同时撒网,一堆仓库一起躺。

    应对的话:

    • 立刻升级:google/gemini-cli 到 0.39.1+,run-gemini-cli 到 0.1.22+
    • 如果暂时升不了,先在CI环境里把工作区目录做只读隔离,或者干脆禁用非交互模式下的自动加载
    • 定期审计.gemini/这类隐藏目录,尤其是来源不明的PR

    说实话这类供应链漏洞以后只会更多,AI工具现在权限越给越大,攻击面也跟着涨。以后搞AI集成的项目,建议默认最小权限,别啥都往runner里塞。