Explainers

Gemini CLI、Cursorのコード実行脆弱性が修正される

GoogleのGemini CLIとAI搭載IDE Cursorにクリティカルな脆弱性が存在し、広範なコード実行の可能性があったが、これらが修正された。CI/CDパイプラインや開発者のワークフローに影響を与え、深刻なリスクを伴うものだった。

{# Always render the hero — falls back to the theme OG image when article.image_url is empty (e.g. after the audit's repair_hero_images cleared a blocked Unsplash hot-link). Without this fallback, evergreens with cleared image_url render no hero at all → the JSON-LD ImageObject loses its visual counterpart and LCP attrs go missing. #}
サーバー上で実行されるコードと、セキュリティを示す鍵のアイコンのイラスト。

Key Takeaways

  • GoogleはGemini CLIのクリティカルなCVSS 10.0 RCE脆弱性を修正、CI/CDパイプラインに影響していた。
  • 別途、Cursor IDEにクリティカルな脆弱性(CVE-2026-26268、CVSS 8.1)が存在し、Gitフックを介したコード実行を可能にしていた。
  • 両方の脆弱性は、AIツールが開発ワークフローや外部入力とやり取りする際のセキュリティリスクを浮き彫りにしている。

最大深刻度、修正済み。

Googleはついに、そのGemini CLIツール、具体的には@google/gemini-cli npmパッケージとgoogle-github-actions/run-gemini-cli GitHub Actionsワークフローに影響していたCVSS 10.0の脆弱性を修正した。これは単なる軽微なバグではない。攻撃者がエージェントのサンドボックスが初期化される前に、セキュリティ対策を迂回してホストシステム上で直接任意のコマンドを実行できる潜在的な経路だ。Novee Securityがこの問題を指摘しており、権限のない外部攻撃者がGeminiの設定として自身の悪意あるコンテンツをロードさせ、コマンド実行を引き起こすことが可能だった。これはCLIのバージョン0.39.1および0.40.0-preview.3、そしてGitHub Actionのバージョン0.1.22より前のものに影響する。

問題の核心は? 以前のバージョンでは、CI環境(ヘッドレスモードと呼ばれる)で実行されるGemini CLIは、ワークスペースフォルダを自動的に信頼していた。つまり、丁寧に確認することなく設定ファイルや環境変数をロードしていたのだ。これは、ユーザー提出のプルリクエストをレビューするCIワークフローのようなシナリオでは、潜在的に壊滅的だ。攻撃者が信頼されていないフォルダに特別に細工された設定を仕込むことができれば、CI/CDパイプラインをサプライチェーン攻撃の発射台にされてしまう可能性があった。これは、暗黙的なコンテキストを過度に信頼した典型的なケースだ。

Googleの修正では、設定ファイルが読み込まれる前にフォルダを明示的に信頼する必要がある。ユーザーには2つの選択肢が提示されている。信頼できる共同作業者からの入力でワークフローを実行する場合は、GEMINI_TRUST_WORKSPACE: 'true'を設定する。信頼できない入力を扱う場合は、Googleのワークフロー強化ガイドラインに従い、環境変数を設定することが推奨されている。また、--yoloモードでのツール許可リストも強化され、プロンプトインジェクションを介したコード実行につながる可能性があった信頼できない入力による許可リストのバイパスシナリオを防いでいる。この変更により、古い動作に依存していた一部のワークフローは壊れる可能性があり、ツールの許可リストの更新が必要になる。

Cursorのコード実行の謎

しかし、それだけではない。このGemini CLIの開示と同時に、AI搭載IDEであるCursorにも深刻な脆弱性が存在するというニュースが舞い込んできた。バージョン2.5(CVE-2026-26268、CVSS 8.1)より前、Cursorは.git設定を介したサンドボックスエスケープを抱えていた。このエクスプロイトにより、悪意あるエージェントがベアリポジトリ内に悪意のあるGitフックを設定できた。そのコンテキストでのコミット操作ごとにこのフックがトリガーされ、ユーザーの操作なしに任意のコード実行につながる。公開リポジトリをクローンし、Cursorで開き、「コードベースを説明して」と尋ねたら、AIエージェントが悪意のあるGitフックに自律的にナビゲートしたせいで、お使いのマシンが侵害されるのを想像してみてほしい。これは、AIエージェントが完全に制御していないリポジトリに対してGit操作を実行するという、より深い問題点を浮き彫りにしている。

「根本原因はCursorのコア製品ロジックの欠陥ではなく、Gitにおける機能の相互作用の結果であり、AIエージェントが制御していないリポジトリ内で自律的にGit操作を実行し始めると悪用可能になる。」

開発者にとってなぜ重要なのか?

これはGoogleやCursorだけの問題ではない。AI支援ツールを開発パイプラインで利用しているすべての開発者や組織にとって、厳しい警告となる。これらのツールがCI/CDのような複雑なワークフローに容易に統合されることで、新たな攻撃対象領域が生まれる。特に外部からの入力を処理する自動化されたパイプラインで、リポジトリの内容を自動的に信頼することは、悪用されるのを待つ脆弱性だ。AI開発ツールの市場は爆発的に拡大しており、これらのツールがより強力で統合されるにつれて、セキュリティへの潜在的な影響(肯定的にも否定的にも)は指数関数的に増大する。ここのイノベーションのスピードは、しばしばセキュリティ強化のスピードを上回り、このようなインシデントは痛みを伴う追いつきとなる。

歴史を振り返ると、npmやPyPIのようなパッケージマネージャーの台頭でも同様のパターンが見られた。開発を簡素化する各イノベーションは、セキュリティ第一の考え方で管理されなければ、広範な侵害の潜在的なベクトルも導入する。Gemini CLIとCursorの脆弱性は、この継続的なサイバーセキュリティの課題の最新の繰り返しに過ぎない。開発プロセスにおける自動化とAI統合の方向への移行は、これらのツールが基盤となるシステムや外部データソースとどのように相互作用するかについての警戒心を比例して高めることを要求する。信頼は、コード実行が関わる場面では特に、当然のものではなく、勝ち取るものでなければならない。

広く使われているGemini CLIのようなツールに、特定のモードに限定されるとはいえ、CVSS 10.0の脆弱性が存在するという事実は、憂慮すべきだ。これは、AIがますます積極的な役割を果たす中で、ソフトウェアサプライチェーンのセキュリティを確保するための継続的な闘いを浮き彫りにしている。開発者は、これらのAIエージェントに自身の環境内で与えられている権限と信頼レベルを極度に意識する必要がある。これはセキュリティの新たなフロンティアであり、過去の脆弱性から学んだ教訓はかつてないほど関連性がある。


🧬 関連インサイト

よくある質問

Gemini CLIの脆弱性により、攻撃者は何ができますか?

悪意のある設定ファイルをロードするようにツールを欺くことで、ホストシステム上で任意のコマンドを実行させ、サンドボックスセキュリティをバイパスできます。

Cursorの脆弱性はどのように機能しますか?

Gitの機能の相互作用、特にリポジトリ内の悪意のあるGitフックを悪用し、AIエージェントがGit操作を実行する際にコード実行を達成します。

ヘッドレスモードでGemini CLIを使用しない場合、影響を受けますか?

Googleによると、Gemini CLIの脆弱性はツールのヘッドレスモードを使用するワークフローに限定されています。しかし、常に警戒を怠らないことが推奨されます。

Written by
Threat Digest Editorial Team

Curated insights, explainers, and analysis from the editorial team.

Worth sharing?

Get the best Cybersecurity stories of the week in your inbox — no noise, no spam.

Originally reported by The Hacker News