Gemini CLI に CVSS 10.0 RCE、Cursor にも 2 件 — AI コーディングエージェントが拡げる攻撃面

この記事は約15分で読めます。

2026年4月下旬から末にかけて、AI コーディングエージェント領域の脆弱性が立て続けに表面化しました。Google は @google/gemini-cli および GitHub Action run-gemini-cli に対して、CI / headless 実行を中心に影響する CVSS 10.0 のリモートコード実行（RCE）脆弱性を修正しました。Cursor 側では 2 月公開済みの CVE-2026-26268（Git hooks 経由のサンドボックス脱出）の詳細が 4 月末に発見者から公表され、さらに 4 月 28 日には未パッチの認証情報窃取問題「CursorJacking」が LayerX から公開されました。

本稿は 3 件を横断的に整理し、AI コーディングエージェントが「自然言語の指示から自律的にコマンドや Git 操作を実行する」前提で組み込まれた現代の開発環境において、攻撃面がどう再定義されつつあるのかを実務視点でまとめます。

1. Gemini CLI：CVSS 10.0 の RCE — headless モードと --yolo の二重バイパス

Google は 2026 年 4 月 24 日付で、GitHub Security Advisory GHSA-wpqr-6v78-jr5g を公開しました。Severity は Critical（10.0）、CVSS 3.1 ベクトルは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H。発見と報告は Novee Security の Elad Meged 氏と Pillar Security の Dan Lisichkin 氏によるもので、Google の Vulnerability Rewards Program 経由で報告されました。CVE 識別子は本稿執筆時点で未付与です。

影響範囲とパッチ

パッケージ 影響バージョン 修正バージョン
@google/gemini-cli（npm） < 0.39.1
< 0.40.0-preview.3		 0.39.1
0.40.0-preview.3
google-github-actions/run-gemini-cli < 0.1.22 0.1.22

Google アドバイザリは「これは Gemini CLI GitHub Action のすべてに影響する」と明記しています。run-gemini-cli の README では gemini_cli_version の既定値が latest とされており、明示的にバージョン固定をしていないワークフローは通常最新の修正版を取得します。一方、gemini_cli_version でバージョン固定をしているワークフローはパッチ適用とワークフロー設定の監査が推奨されています。

攻撃チェーン：信頼境界の二重バイパス

Google アドバイザリは、根本原因として以下 2 つのバイパス技法を挙げています。

(1) Folder Trust in Headless Mode（headless モードでのフォルダ信頼）：従来の Gemini CLI は CI 環境（headless モード）で動作する際に、ワークスペースフォルダを設定ファイル・環境変数の読み込みのために自動的に信頼していました。これは、たとえば外部からのプルリクエストをレビューする CI ワークフローのように、信頼できないディレクトリの内容を扱うケースで危険になります。攻撃者が .gemini/ ディレクトリ配下に悪意ある環境変数を含むファイルを配置した状態で CI が動けば、設定ロードの過程でホスト上のコマンド実行に到達し得ます。

(2) Tool Allowlisting under --yolo（--yolo モードでのツール許可リスト無視）：従来の Gemini CLI は --yolo モード時、~/.gemini/settings.json 内の細粒度ツール許可リストを無視していました。たとえば run_shell_command(echo) のように echo のみを許可する設定でも、実際には任意のシェルコマンドが許可される状態でした。CI ワークフローで信頼できない入力（外部から送られた issue やコメントなど）と --yolo + シェル系ツール許可を組み合わせていた場合、プロンプトインジェクション経由で RCE に到達し得ました。

発見者である Novee Security のレポートはこの構造を「プロンプトインジェクションも、モデルの判断も介在しない。エージェントのサンドボックスが初期化される前の段階で、攻撃者制御コンテンツがエージェント設定として静かに受け入れられ、ホスト上で実行される」と表現しています。LLM 起因の脆弱性というよりは、CI 上のエージェント実行基盤そのものに信頼境界の取り扱い不備があった、と読むほうが正確です。

修正の副作用 — 実務摩擦：CI ワークフローの破壊的変更

今回の修正は破壊的変更を伴います。Google アドバイザリは「headless モードでフォルダ信頼を行わない場合、ワークフロー設定をマニュアルでレビューしないと .env などの設定ファイルがロードされなくなる」と明記しており、既存 CI が暗黙に .gemini/ を読み込む前提だった場合、パッチ後に「無言で失敗する」可能性が示されています。

運用側に求められる対応は、Google が提示する 2 択のいずれかです。

  • ワークフローが信頼できる入力（社内コラボレーターの PR など）のみを扱う場合：GEMINI_TRUST_WORKSPACE: 'true' を環境変数に設定する
  • 信頼できない入力を扱う場合：run-gemini-cli リポジトリのハードニングガイドに従ってワークフローをレビューしたうえで、明示的に信頼設定を行う

つまり「パッチを当てれば終わり」ではなく、「どのワークフローをどちら側に分類するか」を運用者が再評価する必要があります。--yolo 利用ワークフローも同様で、ツール許可リストを実態に合わせて修正しないと、これまで動いていたコマンドが暗黙に却下される可能性があります。

2. Cursor CVE-2026-26268：bare リポジトリと Git hooks によるサンドボックス脱出

Cursor は 2026 年 2 月 13 日付で GitHub Security Advisory GHSA-8pcm-8jpx-hv8r を公開し、CVE-2026-26268 を割り当てています。Cursor 公式が付与した CVSS は 8.1（High）、CVSS 3.1 ベクトルは AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H。影響は 2.5 未満の全バージョンで、Cursor 2.5 で修正済みです。

CVSS 評価が分かれている点

本脆弱性の CVSS 評価には複数のソースが存在します。CVE.org（MITRE）に登録された一次データでは、CNA である GitHub_M が付与した CVSS 8.1（High、ベクトル CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H）が記載されています。これは Cursor 公式 GHSA-8pcm-8jpx-hv8r の値と一致しています。一方、CSO Online の報道によれば、NVD は独自分析の結果として CVSS 9.9（Critical）を付与しており、Cursor 側はこれに異議を唱えて 8.0 相当を主張しているとのことです。

本稿ではベンダー公式かつ CVE.org 一次データに採用されている 8.1 を本文の主値として扱いますが、社内 SLA や脆弱性管理ポリシーで NVD のスコアを採用している場合は 9.9（Critical）として処理される可能性があるため、両方を確認したうえで自社基準に照らした判断が必要です。

攻撃チェーン

Cursor アドバイザリは、攻撃シナリオとして「悪意あるエージェント（プロンプトインジェクション経由）が、保護が不十分な .git 設定（Git hooks を含む）に書き込みを行うことで、次回のフック発火時にサンドボックス外で RCE が成立する」と説明しています。

4 月 28 日に Novee Security が公開した詳細レポートでは、Git の正規機能 2 つの組み合わせが鍵だと整理しています。

  • Git hooks：commit や checkout などのイベントに応じて自動実行されるスクリプト。.git ディレクトリ配下に置かれ、通常は Git で追跡されない
  • bare リポジトリ：作業ディレクトリを持たない Git リポジトリ。これを通常リポジトリの内部にネストできる

攻撃者は、正規に見えるリポジトリの内部に bare リポジトリをネストし、その中に悪意ある pre-commit hook を仕込んでおきます。Cursor のエージェントが Cursor Rules や自然言語指示に従って git checkout をネストされたリポジトリ文脈で実行した時点で、フックが自動発火し、ユーザーへのプロンプトも警告も出さずにホスト上のコード実行に至ります。

発見者として Cursor 公式アドバイザリは Novee Security Research Team、Daniel Teixeira（Nvidia AI Red Team）、Philip Tsukerman の 3 者をクレジットしています。Novee 単独の発見ではない点に留意が必要です。

構造的なポイント

Novee は「リポジトリをクローンする」「エージェントに普通のタスクを依頼する」という日常的アクション 1 回で攻撃者制御コードの実行に到達する点を脅威モデルの変化として強調しています。従来のクライアントサイド攻撃が「悪意あるファイルを開く」「スクリプトを実行する」といった人間の意図的アクションを必要としていたのに対し、AI エージェントが自律的に Git 操作を行う前提では、そのハードルが消失します。

3. CursorJacking：LayerX が公開した未パッチの認証情報窃取問題

これはベンダーが採番した CVE ではなく、LayerX が 2026 年 4 月 28 日に公開した研究報告です。LayerX が付与した CVSS は 8.2、CVE 識別子は本稿執筆時点で未付与で、Cursor 側のアーキテクチャ修正は 4 月 28 日時点で出ていないと LayerX のディスクロージャ・タイムラインに記載されています。

脆弱性の内容

LayerX が付与した CVSS は 4.0 ベースでベクトルは CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N です。Attack Vector が L（Local）である点は重要で、攻撃の前提として「悪意ある拡張機能が Cursor 上にインストールされている状態」が必要です。逆に言えば、その前提さえ成立すれば追加のユーザー操作なしで認証情報を抜き取れる、という構造です。

LayerX によれば、少なくとも macOS では Cursor の API キーやセッショントークンは ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb に保存されており、OS の保護ストレージ（Keychain など）は使われていません。Windows / Linux インストールに同じ問題があるかどうかについて LayerX 公式ページは macOS パスのみを提示しており、二次ソースでは他 OS でも同様であるとの報告がありますが、本稿では一次ソースに合わせて macOS のケースを主軸とします。

問題は、Cursor が拡張機能とこの DB との間にアクセス制御境界を設けていない点です。インストール済みの拡張機能であれば、宣言された権限に関係なく、この DB を直接読み出して認証情報を抽出できます。LayerX は概念実証用の拡張機能を GitHub で公開しており、攻撃ステップは「DB を開く」「クエリで認証情報を抽出する」「fetch() で外部に送信する」だけで成立すると説明しています。

ベンダー対応：「ローカルアプリと同じ信頼境界」回答

LayerX は 2026 年 2 月 1 日に Cursor へ脆弱性を報告しました。Cursor は 2 月 5 日に回答を行っており、LayerX のディスクロージャ・タイムラインに掲載された Cursor 側コメントは「拡張機能が認証情報を含むローカル SQLite DB にアクセスできることは確かだが、これはユーザーがすでにインストールおよび権限付与を行ったローカルマシン上に限られる。これは他のローカルアプリケーションと同じ信頼境界であり、ローカルファイルシステムへのアクセスを持つ悪意あるアプリケーションは、いずれもさまざまなアプリのデータストアにアクセスできる可能性がある」というものでした。Fix status は LayerX が公開した時点で「Not Fixed（2026 年 4 月 28 日）」のままです。

Cursor の回答は技術的には一貫しています。ローカルアプリが互いにファイルシステム上の認証情報を読みうる、という前提自体は伝統的なデスクトップアプリのモデルとして広く共有されています。一方で、VS Code を含む現代の IDE では、サードパーティ拡張機能エコシステムが活発であり、利用者の多くは「拡張機能 = アプリ本体と同じ信頼レベル」とは想定していない可能性があります。LayerX は推奨対処として、機密認証情報を OS レベルキーチェイン（macOS Keychain や Windows Credential Manager）のような保護されたストレージで扱うことを挙げています。

実務上の影響

API キーが盗まれれば、OpenAI や Anthropic の請求被害（攻撃者による不正利用）、保管されているプロンプト履歴・ソースコードのメタデータ流出、連携サービスへの横展開につながります。LayerX は野生での悪用は確認していないと述べていますが、PoC は公開済みで、過去には Cursor マーケットプレイス経由で配布された悪意ある拡張機能（「Solidity Language」を装ったもの）による暗号資産窃取事案も報じられています。

4. 共通テーマ：エージェント自走が再定義する攻撃面

3 件を横並びで見ると、共通する構造があります。

従来のコーディングツールは「受動的」でした。ユーザーが明示的に開いたファイル、明示的に実行したコマンド、明示的に承認したアクションが攻撃の起点になり得ます。エージェント機能はこの前提を変えます。自然言語の指示を解釈し、Git 操作・ファイル書き込み・シェル実行を自律的に決定する設計が前提になると、「リポジトリをクローンする」「拡張機能を 1 つ入れる」「CI に PR を投げる」といった操作 1 回で、攻撃者制御コンテンツがエージェント実行コンテキストに到達し得ます。

具体的には次のパターンが今回まとめて表面化しました。

  • Gemini CLI：CI が外部入力を扱うときに、エージェント設定ファイル（.gemini/）が暗黙に信頼される設計だった
  • Cursor（CVE-2026-26268）：エージェントが git checkout を自律実行することで、ネストされた bare リポジトリの hooks が自動発火する
  • CursorJacking：拡張機能エコシステムが認証情報 DB と同じ信頼レベルで動作するため、1 つの拡張機能が API キー全量を握れる

いずれも個別技術としては既知の概念（フォルダ信頼、Git hooks、ローカルストレージ権限）の組み合わせで成立しています。新しいのは、AI エージェントの自律実行という要素が「悪意あるコンテンツに到達する経路」を従来想定よりはるかに短くしている点です。

5. 実務者向けの推奨対処

Gemini CLI / run-gemini-cli を使っている場合

  • @google/gemini-cli を 0.39.1 または 0.40.0-preview.3 へ、run-gemini-cli を 0.1.22 へ更新する
  • 既存ワークフローを「信頼できる入力のみ扱う」「信頼できない入力を扱う」で分類し、前者には GEMINI_TRUST_WORKSPACE: 'true' を、後者には Google のハードニングガイドに沿った設定を適用する
  • --yolo モード利用時は、~/.gemini/settings.json のツール許可リストを実態に合わせて見直す。修正後はリストどおりに評価されるため、過去動いていたコマンドが暗黙に却下される可能性がある
  • gemini_cli_version でバージョン固定しているワークフローを優先的に監査する

Cursor を使っている場合

  • Cursor を 2.5 以上に更新する（CVE-2026-26268 はここで修正されている）
  • 既知でないリポジトリをクローンする際の運用ルールを再考する。エージェントに git 操作を委ねる前提のワークフローでは、リポジトリ内に意図しない bare リポジトリやフックがないかの初期スキャンが現実的な対策になる
  • CursorJacking 対策として、信頼できない発行元の拡張機能をインストールしない、すでに導入している拡張機能を棚卸する、API キーを定期的にローテートする、必要最小限の権限・利用上限を持つキーを発行する
  • OpenAI、Anthropic、Google の API キーを Cursor に保存する場合、ベンダーレートリミットや使用量アラートを併用して、漏えい時の請求被害を抑える設計にする

組織横断で考える点

AI コーディングツールを開発標準として採用する場合、CI 上のエージェント実行と、開発者ローカル環境上のエージェント実行の双方が、従来の「IDE は受動的」「CI ジョブはサンドボックス的」という前提と異なる挙動を取る前提でリスク評価し直す必要があります。とくに外部 PR・外部 issue を扱う CI と、社内信頼コラボレーターのみを扱う CI を物理的に分けるアプローチは、Gemini CLI 修正で Google が示した方向性とも整合します。

ソース

一次ソース

参考情報

  • The Hacker News: Google Fixes CVSS 10 Gemini CLI CI RCE and Cursor Flaws Enable Code Execution（2026/4/30）
  • CSO Online: Max-severity RCE flaw found in Google Gemini CLI（NVD と Cursor の CVSS 評価差異の出典）

slug: gemini-cli-cvss-10-rce-cursor-vulnerabilities

コメント

タイトルとURLをコピーしました