Gemini CLI v0.60.0とv0.61.0、セキュリティ・堅牢化の修正が計13件間接プロンプトインジェクション対策とサンドボックス境界の強化

2026年9月25日未明（日本時間）時点の情報です。 Googleのターミナル向けオープンソースAIエージェント「Gemini CLI」（google-gemini/gemini-cli）のGitHubリポジトリで、9月に出た安定版のうちの2本──2026年9月15日（UTC）公開のv0.60.0と、9月23日（UTC）公開のv0.61.0──のリリースノートを開くと、「What's Changed」欄に並ぶ22件のうち13件が、サンドボックスの隔離・パス境界の検証・認証情報の扱い・プロンプトインジェクション対策といった、セキュリティ・堅牢化を目的とした修正だった（コミットタイトルをもとにした本記事の分類。v0.60.0が14件中11件、v0.61.0が8件中2件）。本記事は両リリースの公式リリースノートと、代表的な4件のマージ済みプルリクエスト（PR）本文を一次ソースとして、この2リリースで何が直されたのかを整理する。

3行まとめ

1. Gemini CLIのv0.60.0（9月15日）とv0.61.0（9月23日）のリリースノートに、セキュリティ・堅牢化を目的とした修正が合わせて13件並んだ（本記事の分類。うち11件がv0.60.0）。
2. 目立つのは、ビルド設定ファイルの改変や信頼できないフラグを介した間接プロンプトインジェクション対策（v0.61.0・PR #29250）と、コンテナ／LXC／macOS Seatbeltにまたがるサンドボックスのファイルシステム境界強化（v0.61.0・PR #29214、v0.60.0の関連PR2件）。
3. v0.60.0にはほかに、MCPのOAuthコールバックへのRFC 9207発行者識別の強制（PR #29117）、同梱のchrome-devtools-mcp由来でビルド成果物に入っていたGoogle CrUX APIキーの除去（PR #29158）など、認証・認証情報まわりの修正も入った。

13件の内訳

リリースノートの「What's Changed」欄に載っているコミットタイトルを、対応するPR番号ごとに分類すると次のようになる（分類は本記事によるもの。表は分類ごとにまとめて並べてあり、リリースノート上の順番とは異なる）。

v0.60.0側は「What's Changed」14件のうち3件（バージョン番号を上げるだけのchore(release)コミットと、過去バージョン向けのChangelog for ...エントリー2件）を除いた11件がすべてこの分類に入る。v0.61.0側は8件のうち、この記事のテーマに入らないのはfix(core): preserve explicit versioned Flash model IDs（モデルID指定のバグ修正）、fix(core): ensure AgentLoopContext properties are preserved across object spread（内部状態のバグ修正）、それにChangelog for ...系とバージョン更新・パッチ用のコミット4件（Changelog for v0.60.0-preview.0・chore(release)によるバージョンbump・Changelog for v0.59.0・fix(patch)によるcherry-pick）で、残り2件が表の間接プロンプトインジェクション対策とサンドボックス境界強化にあたる。

同じ方向の修正は、この2リリースの前から入っている。9月1日（UTC）のv0.58.0にはfix(core): ensure consistent symlink evaluation in ignore path handlingやfix(sandbox): isolate Docker and container runtime sockets and binaries in macOS Seatbeltが、9月8日（UTC）のv0.59.0にはfix(core): prevent SSRF in MCP OAuth metadata discovery and authenticationとfix(core): enforce fail-closed workspace trust and filter mcpServers in restricted modeが載っている。9月の安定版4本（v0.58.0〜v0.61.0）のうち、この種の修正が最も多く並んだのがv0.60.0だった。

間接プロンプトインジェクション対策の中身（PR #29250・v0.61.0）

PR #29250の本文は、対策の狙いをこう説明している。

This PR implements robust mechanisms to improve workspace boundary validation (specifically focusing on build configuration files and external command parameters) under restricted workspace mode. It refactors built-in execution paths (including shell, edit, and write_file) to check for command flags or arguments guided by external context tags (such as Google Docs, Buganizer, web fetch, or MCP server responses) and require explicit user confirmation.

（このPRは、restricted workspaceモード下でのワークスペース境界検証──特にビルド設定ファイルと外部コマンドパラメータに焦点を当てて──を改善する仕組みを実装する。shell・edit・write_fileを含む組み込みの実行パスを見直し、Google Docs・Buganizer・web fetch・MCPサーバーの応答といった外部コンテキストのタグに誘導されたコマンドフラグや引数を検知して、明示的なユーザー確認を要求するようにする）

具体的な仕組みとして、PR本文は「Build Configuration Tracking」という項目でこう続けている。

Implemented tracking of build configuration files (e.g., package.json, Makefile, pyproject.toml, BUILD.bazel) when edited or created. If build configuration changes are detected within the current session, any subsequent build or test command execution (such as npm run, make, cargo, blaze) is surfaced for explicit user confirmation.

（package.json・Makefile・pyproject.toml・BUILD.bazelといったビルド設定ファイルが編集・作成された際の追跡を実装した。現在のセッション内でビルド設定の変更が検出された場合、それ以降のnpm run・make・cargo・blazeといったビルド／テストコマンドの実行は、明示的なユーザー確認のために表示されるようになる）

PR本文の説明に沿って読むと、外部から取り込んだ文書やWebページ、MCPサーバーの応答に紛れ込んだ指示でビルド設定ファイルが書き換えられ、そのままビルド・テストコマンドが走る、という間接プロンプトインジェクションの経路に、ユーザーの明示的な確認を挟む修正ということになる。PR本文が対象として書いているのはrestricted workspaceモード下での動作で、それ以外のモードでどう振る舞うかはこの本文からは分からない。「Related Issues」欄にはRelated to FixBug-cla-445881265とあるが、この文字列はPRの作業ブランチ名と同じで、どの課題を指すのかはPRページからは分からなかった。

サンドボックスのファイルシステム境界はどう変わったか（PR #29214ほか）

v0.61.0のPR #29214は、コンテナ（Docker／Podman／runsc）・LXC・macOS Seatbeltの3系統にまたがるサンドボックス実装を対象にしている。本文の要約はこう書かれている。

Hardens sandbox filesystem boundaries by isolating sandbox runtime state from host configuration directories, replacing host directory mounts with sanitized configuration files, standardizing on realpath resolution during path sensitivity checks with non-existent path existence fallbacks, validating working directory paths against sensitive host locations prior to mounting across container runtimes, LXC, and macOS Seatbelt...

（サンドボックスのランタイム状態をホストの設定ディレクトリから隔離し、ホストディレクトリのマウントをサニタイズ済みの設定ファイルに置き換え、パスの機微性チェックにおけるrealpath解決を標準化し、存在しないパスへのフォールバックを備え、コンテナランタイム・LXC・macOS Seatbeltをまたいでマウント前に作業ディレクトリのパスを機微なホスト上の場所と照合する、という形でサンドボックスのファイルシステム境界を強化する）

詳細欄には、より具体的な禁止事項も書かれている。

Prohibited mounting the host user's root configuration directory (~/.gemini), host home directory, or any of their parent directories (e.g. /home, /) into containers.

（ホストユーザーのルート設定ディレクトリ~/.gemini、ホームディレクトリ、およびそれらの親ディレクトリ（/homeや/など）をコンテナにマウントすることを禁止した）

このPRはv0.61.0の1件だが、v0.60.0にもサンドボックス関連の修正が2件（macOS Seatbeltの一時ディレクトリ分離・サンドボックスコンテナ内の設定ディレクトリ分離）入っており、さらに前のv0.58.0にもmacOS SeatbeltでのDocker／コンテナランタイムのソケットとバイナリの隔離が入っている。サンドボックスの隔離強化は9月のリリースを通して続けて行われている。

MCPのOAuthとハードコードされたAPIキー（PR #29117・#29158、いずれもv0.60.0）

PR #29117は、Gemini CLIがMCPサーバーとOAuth連携する際のコールバック処理に、RFC 9207（OAuth 2.0 Authorization Server Issuer Identification）の発行者識別を導入する修正だ。

Implements RFC 9207 (OAuth 2.0 Authorization Server Issuer Identification) validation in Gemini CLI's MCP OAuth flow to ensure response origin consistency and prevent unintended token routing.

（Gemini CLIのMCP OAuthフローにRFC 9207（OAuth 2.0 Authorization Server Issuer Identification）の検証を実装し、応答の発行元の一貫性を保証し、意図しないトークンのルーティングを防ぐ）

PR本文の「Compatibility Note for MCP Developers」には、この変更が既存のMCPサーバー運用者に及ぼす影響も明記されている。

Remote MCP servers using OAuth must ensure their Authorization Server supports RFC 9207 by returning the iss parameter in the callback redirect (/oauth/callback?code=...&state=...&iss=https://<issuer>). If an expected issuer is configured or discovered for the MCP server, callback responses missing iss will be rejected.

（OAuthを使うリモートMCPサーバーは、コールバックのリダイレクト（/oauth/callback?code=...&state=...&iss=https://<issuer>）でissパラメータを返すことで、自身の認可サーバーがRFC 9207に対応していることを保証しなければならない。MCPサーバーに期待される発行者が設定または検出されている場合、issを欠いたコールバック応答は拒否される）

もう1件、PR #29158は毛色が違う。Gemini CLIが同梱しているMCPサーバーchrome-devtools-mcp（バージョン0.19.0）にGoogleのChrome UX Report（CrUX）APIキーが平文で書き込まれており、Gemini CLI側のバンドル処理でそのままビルド成果物に入っていた、という問題への対処だ。

At compile time, chrome-devtools-mcp@0.19.0 hardcodes a plaintext Google CrUX API key. When npm run bundle:browser-mcp compiles this dependency, the key gets embedded inside packages/core/dist/bundled/chrome-devtools-mcp.mjs and packages/core/dist/bundled/third_party/index.js, which eventually end up in the Docker container image layer.

（コンパイル時、chrome-devtools-mcp@0.19.0はGoogle CrUX APIキーを平文でハードコードしている。npm run bundle:browser-mcpがこの依存関係をコンパイルすると、そのキーはpackages/core/dist/bundled/chrome-devtools-mcp.mjsとpackages/core/dist/bundled/third_party/index.jsに埋め込まれ、最終的にDockerコンテナイメージのレイヤーに含まれることになる）

PR本文の「Related Issues」欄は、CWE-798（ハードコードされた認証情報の使用）として報告された問題の修正だと書いている。修正方法は、バンドル後の後処理でこのキーの文字列をprocess.env.CRUX_API_KEY || ""という実行時参照に自動で置き換えるというものだ。PR本文が説明しているのはビルド成果物の中の文字列の置き換えで、キーそのものを失効させたかどうかは、本記事が読んだPRページ（本文とコメント）には書かれていなかった。キーの文字列は本記事では再掲しない。

13件の提出者は7アカウント、マージしたのは13件とも同じアカウント

両リリースの「What's Changed」欄の各行には、提出者のアカウント名が付いている。表の13件について数えると、diegogodinezr（3件・#29120／#29169／#29214）・jvargassanchez-dot（3件・#29117／#29171／#29216）・amelidev（2件・#29158／#28863）・jesussamuel-byte（2件・#29170／#29115）・villahernandez-coder（1件・#29250）・luisfelipe-alt（1件・#29215）・urielefrenvirtusa（1件・#29116）の7アカウントだった。13件のPRページを開くと、どのページの見出しにもDavidAPierceがgoogle-gemini:mainへマージしたと表示されていた（2026年9月25日確認）。このうちurielefrenvirtusaは、v0.60.0のリリースノートの「New Contributors」欄に、NTFSの8.3短縮ファイル名の修正（PR #29116）が初めての貢献だったと記載されている。各アカウントの所属は、リリースノートとPR本文からは分からなかった。

13件にCVE番号は付いているか

2026年9月25日（日本時間）時点で、google-gemini/gemini-cliのSecurity Advisoriesページ（/security/advisories）は「There aren't any published security advisories」と表示していた。13件のPRページ（本文とコメント）とリリースノートにも、CVEやGHSAの番号は書かれていなかった。別の経路として、npmパッケージ@google/gemini-cliをオープンソース脆弱性データベースOSVのAPIで照会すると、返ってきたのは2026年4月24日公開のGHSA-wpqr-6v78-jr5g（CVE-2026-12537・CVE-2026-13745。ワークスペース信頼とツール許可リストの迂回によるリモートコード実行で、安定版での修正は0.39.1）の1件だけだった。本記事が確認した範囲では、今回の13件に対応する番号は見つからなかった。

日時として確かなのはリリースの公開時刻まで

表の13件のうち、本記事で本文を引用したのはPR #29250・#29214・#29117・#29158の4件で、残り9件はコミットタイトルとPR冒頭の要約をもとに分類している。個々のPRがいつマージされたかは追っておらず、日時として示せるのはリリースの公開日時──v0.60.0がUTC 2026年9月15日20:31:02、v0.61.0がUTC 2026年9月23日23:59:15（日本時間ではそれぞれ9月16日05:31、9月24日08:59）──だけだ。9月のどの時点で各修正が着手・レビューされたかという時系列は、この2つの公開日時からは分からない。

読んだリリースノートとPR

• google-gemini/gemini-cli Release v0.61.0（GitHub、公開日時 UTC 2026-09-23T23:59:15Z）
• google-gemini/gemini-cli Release v0.60.0（GitHub、公開日時 UTC 2026-09-15T20:31:02Z）
• Release v0.59.0／Release v0.58.0（前の2リリースとの比較に使用）
• PR #29250／PR #29214／PR #29117／PR #29158（本文を引用した4件）
• Security Advisories — google-gemini/gemini-cli（CVE/GHSA番号の記載有無を確認）

関連記事: Gemini CLIの使い方【2026年9月】 / 生成AIのセキュリティリスク──企業が押さえるべき6つの脅威と対策 / Agent Safehouse（macOSサンドボックス） / huggingface_hubのresolve_revisionとパストラバーサル脆弱性修正

感想・指摘はコメント欄へ。