Google Gemini CLIにCVSS 10.0のRCE脆弱性、CIパイプライン経由のサプライチェーン侵害リスク

「CVSS 10.0って実際にどれくらい危ないんだ？」
「Gemini CLIをCIに組み込んでいるが、影響範囲はどこまで？」

チップス

ボス、Google Gemini CLIに最大スコアの脆弱性が出たでしゅ。CVSS 10ってめったに見ないんでしゅ……

ボス

未認証のRCEが成立する条件が整えば、満点は珍しくない。Geminiの利用が広がる中、CIパイプラインを抱える組織は今すぐ確認しておきたい話題だな。

Googleが提供するGemini CLIに、CVSS 10.0のリモートコード実行(RCE)脆弱性が公開され、修正版がリリースされました。
本記事では、攻撃成立の仕組み、CI環境への影響、そして日本のAI活用組織がいま取るべき対応を順を追って整理します。

CIパイプラインでAIアシスタントを動かしている組織にとって、対応漏れがそのままサプライチェーン侵害につながりかねません。
最後まで読めば、なにを優先すべきかが具体的に把握できます。

脆弱性の概要

まずはGoogleの公表内容から、攻撃成立条件をおさえます。

ヘッドレス信頼設定の不備

本脆弱性は、Gemini CLIをヘッドレスモードで実行した際に、ワークスペースとなるフォルダーを自動的に「信頼済み」と扱ってしまう設計に起因します。
その結果、攻撃者が用意したGemini設定ファイルがロードされ、サンドボックス初期化前に任意コマンドが実行されます。
悪意ある環境変数を経由して埋め込み可能なため、リポジトリ単位の信頼境界では防ぎきれません。

修正と必要な明示的信頼

Googleの修正では、設定ファイルにアクセスする前にフォルダーの信頼を明示的に与える必要があります。
これにより、攻撃者が外部から差し込んだ設定が無条件にロードされる経路が遮断されます。
同時にCursorで2件の高深刻度脆弱性(CVE-2026-26268、CursorJacking)も判明しており、AI開発ツール全体での点検が望まれます。

チップス

AI関連ツールが続々と脆弱性を出すと、開発環境ぜんぶ見直さないといけないでしゅね……

CI環境への影響と対策

とくにGitHub Actionsを多用する組織で、被害が広がる前に取るべき対応を見ていきます。

サプライチェーン侵害のリスク

悪意あるOSSプロジェクトに偽装したリポジトリでGemini CLIを実行すれば、CIランナー上で攻撃者のコードが動きます。
結果として、リポジトリのシークレット、デプロイキー、認証情報が窃取され、本番環境への横展開につながる恐れがあります。
近年のサプライチェーン攻撃の典型的な経路と一致するため、対応の優先度はきわめて高い領域です。

推奨される対応ステップ

まずはCI上のGemini CLIおよびActionsのバージョンを棚卸しし、修正版へ即時更新するのが第一歩です。
つぎに、外部リポジトリの自動チェックアウトや信頼設定が必要以上に広がっていないかを確認します。
万一、対象バージョンを利用していた場合は、CIで使用していたシークレットの再発行・ローテーションを検討してください。

まとめ

Gemini CLIのRCE脆弱性は、AI支援開発が当たり前になった現場で「信頼境界の自動拡張」が引き起こすリスクを象徴する事例です。
CIに組み込んだAIツールほど、外部リポジトリの信頼判定や環境変数の取り扱いに目を配る必要があります。
更新と棚卸しに加え、シークレットのライフサイクル管理を再設計するきっかけにしましょう。
引用元:The Hacker News – Google Fixes CVSS 10.0 Gemini CLI CI RCE