無害なコマンドが引き金に Cursorを狙う「環境変数改ざん」の恐怖：「git branch」承認で攻撃コード発動？
Dockerは、AIコーディングエージェントを狙った攻撃事例を紹介した。Cursorの脆弱性「CVE-2026-22708」を例に、コマンドの許可リストだけでは攻撃を防げないこと、取るべき対策を紹介している。
AIコーディングエージェントに「安全なコマンドだけ」を自動実行させれば、リスクを抑えられる。そのように考えて整備したはずが、許可したコマンドそのものが攻撃の引き金になった――。
Dockerは2026年8月18日（米国時間）、AIコーディングエージェントを狙った攻撃事例を紹介した。焦点となったのは、Cursorで見つかった脆弱性「CVE-2026-22708」だ。
この事例が示すのは、AIエージェントのセキュリティ対策では「何のコマンドを実行させるか」だけを制御しても十分ではないということだ。なぜ、一見無害な「git branch」の実行が攻撃につながったのか。企業がAIコーディングエージェントを利用する際に注意すべきポイントを見ていく。
「git branch」を許可しただけなのに攻撃コードが動く？
併せて読みたいお薦め記事
コーディングエージェントとセキュリティ
CVE-2026-22708は、CursorをAuto-Run Modeで利用し、実行可能なコマンドをallowlist（許可リスト）で制御している場合に問題となる脆弱性だ。
この脆弱性は、AIセキュリティプラットフォームPillar Securityの研究者が2026年1月14日に公表したもの。Dockerによると、「export」「typeset」「declare」など一部のシェル組み込みコマンドが許可リストによる確認の対象にならず、ユーザーへの承認要求なしに実行できた。Cursorはこの脆弱性を「High」と評価し、バージョン2.3で修正したという。
攻撃のポイントは、無害なコマンドそのものを悪用するのではなく、そのコマンドが実行されたときの挙動を事前に変更することにある。
例えばGitは、出力を表示するプログラムを決めるために「PAGER」という環境変数を参照する。攻撃者の指示を読み込んだAIエージェントが、ユーザーに見えないところで「export」を使ってPAGERを書き換えたとする。
その後、ユーザーが「git branch」の実行を承認する。「git branch」は通常なら危険性の低いコマンドだ。しかしGitが改ざんされたPAGERを参照すると、攻撃者が仕込んだ別のコマンドが実行される可能性がある。Pillar Securityによる検証では、許可リストを空にした最も厳しい設定でも攻撃が成立したという。
つまりユーザーは、表示されたコマンドを確認し、問題ないと判断して正しく承認している。それでも、コマンドが実際に何をするのかを決める実行環境が先に書き換えられていれば、コマンド名だけを確認する仕組みでは攻撃を防げない。この点が今回の問題の核心だ。
なぜAIコーディングエージェントで危険性が増すのか
環境変数を悪用してプログラムの挙動を変える手法そのものは新しいものではない。Dockerによると、Pillar Securityは、2020年に公開された研究でも同様の手法が示されていたと指摘している。
従来、このような攻撃には、攻撃者が既に端末へ侵入し、複数の設定変更を順番に実行するといった条件が必要だった。しかしAIコーディングエージェントは、その前提を変える可能性がある。AIエージェントはリポジトリ内のファイルを読み、その内容に従って複数の処理を連続して実行できる。しかも一般的には、利用者自身のファイルアクセス権や認証情報を使って処理する。
そのため、READMEや依存関係、IssueのコメントなどにAIエージェント向けの悪意ある指示が紛れ込めば、人間が直接操作しなくても一連の攻撃処理が進む可能性がある。今回の攻撃も、AIエージェントがファイル内の指示を読み、環境設定を変更した後、通常のコマンドを実行するという2段階で成立する。
Pillar Securityの検証では、一連の攻撃によって最終的に被害者のSSH（Secure Shell）秘密鍵が外部へ持ち出される可能性が確認された。権限昇格やメモリ破壊といった典型的な脆弱性を悪用する必要はなく、AIエージェントに既に与えられている権限が利用された形だ。
「許可リスト」をセキュリティ境界と考えない
この事例から企業が学ぶポイントは、AIエージェントのコマンド許可リストを「セキュリティ境界」と捉えないことだ。
許可リストには、「ls」など頻繁に使う安全性の高いコマンドについて、毎回ユーザーに承認を求める煩雑さを減らす役割がある。一方、コマンド名を確認するだけでは、そのコマンドが置かれた環境や前段階の操作まで評価できるとは限らない。
Dockerによると、Cursorのドキュメントも、許可リストを「best-effort」の仕組みと位置付け、回避される可能性があると説明している。Pillar Securityは、許可リストで一つ一つのコマンドを判定するよりも、隔離された環境内でAIエージェントにコマンド実行を許可する考え方を提案しているという。
AIエージェントは「何を実行できるか」より「何に到達できるか」を制限
この対策としてDockerは、AIコーディングエージェントを隔離された軽量な仮想マシン（microVM）で動かす「Docker Sandboxes」を紹介している。Dockerによれば、各Sandboxは独自のカーネルとファイルシステムを持ち、ネットワーク通信もデフォルトで拒否する設計になっている。
重要なのは、Sandboxがプロンプトインジェクションそのものを防ぐわけではない点だ。
同じ攻撃をSandbox内で実行した場合でも、悪意ある指示はAIエージェントに届き、環境変数の変更やペイロードの実行そのものは起こり得るという。一方、ホスト側のSSH秘密鍵がSandbox内になければ、攻撃コードがそのファイルを直接読み取ることはできない。ホスト側の「~/.zshrc」を書き換えて永続化するといった攻撃も、Sandbox内の変更であればSandboxの破棄とともに消える。
ただし、隔離すれば全て安全になるわけではない。Dockerも、ホストと共有しているワークスペースやSSH Agent、複数のSandboxから共有されるAgent Skillsの保存領域などについて注意点を挙げている。SSH秘密鍵そのものを読み取れなくても、転送されたSSH Agentを通じて認証に利用される可能性があるため、接続先をネットワークポリシーで制限する必要があるという。
個人任せではなく、組織としてAIエージェントの権限を決める
もう1つのポイントは、AIエージェントの実行ルールを各開発者のPCごとに設定するのではなく、組織として管理することだ。
Dockerは「Kits」という「YAML」形式の設定を使い、認証情報やネットワークポリシー、環境変数、起動時コマンド、ファイルなどを宣言的に定義できるとしている。例えばネットワークを原則拒否し、業務上必要な接続先だけを許可するといったルールをファイルとして管理し、チームで共通利用できる。
Dockerの「Docker AI Governance」では、管理者がネットワークやファイルシステムに関するポリシーを組織レベルで設定できるとしている。ポリシーに基づく判断について、ユーザーや時刻、適用されたルールを記録し、SIEM（セキュリティ情報イベント管理）へ送信する仕組みもある。
AIコーディングエージェントを利用する際のポイントとしてDockerは、以下3つを挙げる。
- 環境設定を変更するコマンドも他のコマンドと同様に扱うこと
- 許可リストをセキュリティ境界と考えないこと
- 信頼していないコードを実行する前から環境を隔離すること
AIエージェントの能力が高まるほど、読み込んだ全ての指示について「安全かどうか」を正しく判断させることは難しくなる。今回の事例が示しているのは、AIエージェントに危険な命令を実行させないことだけに頼るのではなく、「仮に攻撃コードが実行されても、重要なファイルや認証情報、ネットワークに到達できないようにする」という発想の重要性だ。
企業がAIコーディングエージェントを本格導入する際には、「どのコマンドを許可するか」だけでなく、「AIエージェントをどこで実行するか」「どのファイルや認証情報へアクセスさせるか」「どのネットワークへ接続できるようにするか」まで含めて設計する必要がありそうだ。
本稿は、Dockerが2026年8月18日に公開したCoding Agent Horror Stories: The Command You Already Approvedを基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
