--yolo modeではtool allowlist（使ってよい操作の制限）を無視してしまい、任意コマンド実行につながりえたSecurityWeek が伝えたのは、Google のオープンソースAIエージェント Gemini CLI に存在した重大な脆弱性です。
Gemini CLIは、ざっくり言うと「ターミナルからGoogle Geminiを使えるようにしたAIアシスタント」です。開発者がコマンドライン上でAIに作業を手伝わせる、というあれです。
今回の問題で重要なのは、単に「バグがあった」という話ではなく、AIエージェントが人間の代わりに勝手に動く性質を逆手に取られた点です。
これ、かなりAI時代らしい攻撃だなと思います。昔ながらの脆弱性というより、「便利にした結果、攻撃面も増えた」タイプですね。
Pillar Security によると、問題の中心は indirect prompt injection です。
これは日本語でいうと、**AIへの“間接的な命令注入”**みたいなもの。
AIに「こうしろ」と直接入力するのではなく、たとえば GitHub Issue やコメントなど、AIが参照する外部テキストに悪意ある指示を紛れ込ませる手口です。
今回のシナリオでは、攻撃者が Google の GitHub リポジトリに公開 issue を作成し、その本文に悪意あるプロンプトを隠すことができたとされています。
Gemini CLI の自動トリアージ機能――つまり、Issueを読んで分類・整理するAIの役割――がそれを読み込むと、AIが攻撃者の指示に従ってしまう可能性があったわけです。
しかも --yolo mode では、許可済みツールのチェックを飛ばしてしまうため、AIが使うコマンドが自動承認されます。
yolo は “You Only Live Once” の略で、要するに「細かい確認は省いてガンガン動かす」モードです。開発の現場では便利でも、セキュリティの視点ではかなり怖い。個人的には、名前からしてもう危ういです。便利さの代償がそのまま漏れている感じがあります。
その結果、攻撃者はAIエージェントに任意のコマンドを実行させることができ、さらにビルド環境から内部シークレット（秘密情報）を抜き出して、攻撃者のサーバーに送らせることも可能だったとされています。
ここで怖いのは、被害が「そのIssueを処理した1回で終わる」話ではないことです。
Pillar Security は、盗まれた認証情報から、リポジトリへの書き込み権限を持つトークンへ到達できると指摘しています。そこまで行くと、攻撃者はmainブランチに悪意あるコードを仕込めるわけで、これはもう完全に supply chain attack（供給網攻撃） です。
供給網攻撃というのは、ソフトウェアを作る途中のどこかに悪いコードを混ぜ込み、最終的にそのソフトを使う多数のユーザーにまで被害を広げる攻撃です。
個別ユーザーを狙うより効率がよく、しかも広がりやすい。だから本当に厄介です。
しかも記事では、少なくとも8つのGoogleリポジトリが同じ脆弱なワークフローテンプレートを使っていた可能性があるとされています。
これは単なる一点突破のバグではなく、テンプレートや共通設定を通じて横展開しうる問題だったということ。ここがかなり重要です。
Googleはこの脆弱性を2026年4月24日に修正しました。
修正版は Gemini CLI 0.39.1 で、--yolo mode における tool allowlisting を見直したとのことです。
あわせて、run-gemini-cli GitHub Action も更新されました。
さらに今回のアップデートでは、もう一つの問題も直されています。
それが headless mode における「信頼の甘さ」です。
headless mode というのは、画面操作なしで自動実行するようなモードのことですが、ここで Gemini CLI は現在のワークスペースフォルダを自動的に信頼してしまう挙動がありました。
そのフォルダ内にある設定や環境変数を読み込むため、もし攻撃者がそこに細工をしていたら、credentials（認証情報）や secrets、ソースコードにアクセスされる可能性があったわけです。
これも地味に見えてかなり危険です。
「その場のフォルダを信頼する」のは、便利な自動化ツールではありがちですが、セキュリティ上は一歩間違えると大事故になります。
私が面白いと思ったのは、今回の攻撃が「AIそのものを壊した」というより、AIに“行動権限”を与えすぎたことを突いている点です。
AIエージェントは、単なるチャットボットではなく、ファイルを読んだり、Issueを処理したり、コマンドを実行したりします。つまり、賢い助手というより、かなり権限を持った実行役なんですよね。
だからこそ、入力の中に紛れた指示をそのまま信じてしまうと、AIはあっさり「善良な自動操縦装置」から「攻撃者の手先」に変わってしまう。
この構図は、今後のAI開発でますます増えるのではないかと思います。
特に、以下の組み合わせは危険です。
この4つがそろうと、攻撃者にとってはかなりおいしい標的になります。
逆に言うと、AIエージェントを使う側は「便利だから」で済ませず、どこまで信頼し、どこで止めるかを真面目に設計しないといけません。
「これは開発者向けの話でしょ？」と思う人もいるかもしれません。
でも、間接的な prompt injection は、将来的にはもっといろいろな製品に広がるはずです。
メール、チケット管理、文書要約、社内検索、ブラウザ操作など、AIが“外から来た情報”を読む場面は山ほどあります。
つまり、今回の件は Gemini CLI だけの話ではなく、AIエージェント全般の安全設計に対する警告と見るべきだと思います。
AIが賢くなるほど、攻撃者も「AIの賢さをだます」方向に進化する。なんだか、AIの性能向上と攻撃の高度化が、きれいに追いかけっこになっている感じです。
Gemini CLI の脆弱性は、単なるバグ修正では片づかない、かなり本質的な問題を示しています。
AIエージェントが自動で動くほど便利になる一方で、外部入力をそのまま信じる危険や、自動承認による暴走が現実の攻撃につながることがはっきりしました。
個人的には、これからのAIツールでは「何ができるか」よりも、何を絶対にさせないかの設計がもっと重要になると思います。
便利さを盛れば盛るほど、境界管理をサボった瞬間に一気に崩れる。今回の件は、その典型例ではないでしょうか。
参考: Gemini CLI Vulnerability Could Have Led to Code Execution, Supply Chain Attack