**Google**は、**Gemini CLI** — `@google/gemini-cli` npmパッケージおよび`google-github-actions/run-gemini-cli` **GitHub Actions**ワークフロー — における、ホストシステム上での任意のコマンド実行を可能にする可能性のある、最高レベルのセキュリティ脆弱性を修正しました。 **Gemini CLIのリモートコード実行** 「この脆弱性により、権限のない外部攻撃者が、自身の悪意のあるコンテンツを**Gemini**の設定として読み込ませることが可能でした」と**Novee Security**は水曜日のレポートで述べています。「これにより、エージェントのサンドボックスが初期化される前に、ホストシステム上で直接コマンド実行がトリガーされました。」 この欠陥には**CVE**識別子は割り当てられていませんが、**CVSS**スコアは10.0です。以下のバージョンに影響します： * `@google/gemini-cli < 0.39.1` * `@google/gemini-cli < 0.40.0-preview.3` * `google-github-actions/run-gemini-cli < 0.1.22` 先週公開されたアドバイザリで、**Google**は、この影響は**Gemini CLI**をヘッドレスモードで使用するワークフローに限定されると述べており、フォルダーの信頼なしにヘッドレスモードでツールを使用する場合、この信頼メカニズムを設定するために手動レビューが必要になると付け加えています。 「以前のバージョンでは、CI環境（ヘッドレスモード）で実行される**Gemini CLI**は、設定および環境変数を読み込む目的で、ワークスペースフォルダーを自動的に信頼していました。」と述べています。 現在のワークスペースフォルダーの自動信頼は、ツールがレビュー、サンドボックス化、または明示的なユーザーの同意なしに、見つかったエージェント設定を読み込めることを意味していました。攻撃者は、エージェントを実行しているホスト上でコード実行への道を開くことができる特別に細工された設定を配置することで、この動作を悪用し、事実上CI/CDパイプラインをサプライチェーン攻撃の経路に変えることができました。 アップデートでは、設定ファイルにアクセスする前にフォルダーが明示的に信頼される必要があるようにすることで、問題に対処しています。そのため、ユーザーはワークフローを確認し、次の2つのアプローチのいずれかを採用することが推奨されています： * ワークフローが信頼できる入力（例：信頼できる共同作業者からのプルリクエストのレビュー）で実行される場合は、ワークフローで`GEMINI_TRUST_WORKSPACE: 'true'`を設定します。 * ワークフローが信頼できない入力で実行される場合は、悪意のあるコンテンツに対してワークフローを強化するための**Google**のガイダンスを`google-github-actions/run-gemini-cli`で確認し、環境変数を設定します。 同社はまた、**Gemini CLI**が`--yolo`モードで実行されるように設定されている場合、ツール許可リストを強化する措置を講じていると述べており、ユーザー提出の**GitHub**イシューなどの信頼できない入力が、自動承認モードが`~/.gemini/settings.json`の許可リストを無視し、ユーザー確認なしにすべてのツール呼び出し（「run_shell_command」を含む）を実行するという事実を利用して、プロンプトインジェクションによるリモートコード実行につながる可能性のあるシナリオを防いでいます。 「バージョン0.39.1では、**Gemini CLI**ポリシーエンジンが`--yolo`モードでツール許可リストを評価するようになり、信頼できない入力を処理する際に安全なコマンドをいくつか許可リストに登録するCIワークフローに役立ちます」と**Google**は述べています。「その結果、この動作に依存していた一部のワークフローは、ツール許可リストがタスクに合わせて変更されない限り、サイレントに失敗する可能性があります。」 ### **Cursor**のバグがコード実行につながる  この開示は、**Novee Security**がAI搭載開発ツール**Cursor**のバージョン2.5（**CVE-2026-26268**、**CVSS**スコア：8.1）より前のバージョンにおける高深刻度の脆弱性を指摘したのと同時期に行われました。この脆弱性も、プロンプトインジェクションにより任意のコード実行につながる可能性があります。 **Cursor**は、2026年2月に公開されたアラートで、これを`.git`設定を介したサンドボックスエスケープのケースとして説明しており、不正なエージェントが、埋め込まれたリポジトリコンテキスト内でコミット操作が実行されるたびに自動的にトリガーされる悪意のある[**Git**フック](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)を持つベアリポジトリ（`.git`）を設定できるため、ユーザーの操作なしにコード実行が可能になります。 結果として、以下の手順で被害者のマシン上で自動承認される任意のコード実行が発生します： * ユーザーが悪意のあるpost-checkoutフックを含む埋め込みベアリポジトリを持つ公開**GitHub**リポジトリをクローンします。 * ユーザーがリポジトリを**CursorIDE**で開きます。 * ユーザーが「コードベースを説明して」という無害なプロンプトを投げかけます。 * **Cursor**エージェントがAGENTS.mdを解析し、ベアリポジトリに移動してマスターブランチの「git checkout」を実行するように指示されます。 * ベアリポジトリ内のpost-checkoutフックがトリガーされ、コード実行につながります。 「根本原因は**Cursor**のコア製品ロジックの欠陥ではなく、**Git**の機能の相互作用の結果です。これは、AIエージェントが制御していないリポジトリ内で**Git**操作を自律的に実行し始めた瞬間に悪用可能になります」とセキュリティ研究者のAssaf Levkovich氏は述べています。 「エージェントが通常の要求を満たす一環としてgit checkoutを実行するとき、それはユーザーが暗黙的に承認したもの以外は何も行っていません。しかし、ユーザーもエージェントも、リポジトリの**Cursor**ルールが何を設定したかを知ることはできません。ネストされたベアリポジトリに埋め込まれた悪意のあるpre-commitフックは、エージェントの推論チェーンの外側、ユーザーの視野の外側でサイレントに実行されます。」 ### **CursorJacking**：APIキー窃盗 この発見は、IDEにおけるもう一つの高深刻度アクセス制御脆弱性（**CVSS**スコア：8.2）の発見とも一致しており、インストールされている任意の拡張機能がローカルの**SQLite**データベースに保存されている機密APIキーや認証情報にアクセスできるようになり、アカウント乗っ取り、データ漏洩、不正なAPI使用による経済的損失につながる可能性があります。この問題は、**LayerX**によって**CursorJacking**と名付けられ、まだ修正されていません。 「**Cursor**は、拡張機能とこのデータベース間のアクセス制御境界を強制していません」と**LayerX**の研究者Roy Paz氏は述べています。「この脆弱性の悪用は、セッショントークンやAPIキーの漏洩、**Cursor**バックエンドサービスへの不正アクセス、ユーザーのなりすましによるデータ窃盗につながる可能性があります。」 **Cursor**は、アクセスはユーザーが既に拡張機能をインストールし、権限を付与しているローカルマシンに限定されていると主張しており、これはファイルシステムへのローカルアクセスを持つ不正な拡張機能が、さまざまなアプリケーションデータストアから貴重な情報を抽出できる可能性があることを意味します。この脅威に対抗するためには、ユーザーが信頼できる拡張機能のみをダウンロードすることが不可欠です。