サンドボックスは破られていない――Cursor・Codex・Gemini CLIが書いたファイルを、箱の外の道具が信じて走らせた
Pillar Securityの「Week of Sandbox Escapes」が、Cursor・Codex・Gemini CLI・Antigravityの7件の穴を公開。どれもサンドボックスは破らず、エージェントが書いたファイルを箱の外の道具が信じて実行する構図だった。4つの弱点パターンと、現場で打てる対策を開発者目線で整理する。
コーディングエージェントを「サンドボックス（隔離環境）で動かしているから安全」と考えている現場は多いはずです。イスラエルのセキュリティ企業Pillar Securityが「Week of Sandbox Escapes（サンドボックス脱出の一週間）」と題して公開した一連の調査は、その前提に穴があることを示しました。標的はCursor、OpenAIのCodex、GoogleのGemini CLI、そしてGoogleのAntigravityという、いずれも広く使われる4つのエージェントです。8月中旬にBleepingComputerなどが報じ、改めて注目を集めました。
箱の中では規則を守り、箱の外に道具を仕込む
今回明らかになった7件の問題は、どれもサンドボックスそのものを破ってはいません。エージェントは隔離の中で規則どおりに振る舞い、ただ1つのファイルを書きます。フックの設定、仮想環境のインタープリタ、Gitの設定、タスク定義――こうしたファイルを、サンドボックスの外にいる別の道具が後から信頼して読み込み、実行する。ここが盲点でした。攻撃の引き金は、READMEやIssue、依存パッケージ、差分などに紛れ込ませた間接的なプロンプトインジェクションです。悪意ある指示を読んだエージェントが、開発者のマシン上で「無害な書き込み」を行い、それが箱の外で実行に化けます。
Pillarはこの構図を一言でまとめています。「エージェントの被害範囲は、あとでホストの部品が信頼するもの全てに及ぶ」。プロセスを隔離しただけでは足りない、という指摘です。
繰り返し現れた4つの弱点パターン
調査は、個別のバグではなく再発する構造として4つの失敗モードを挙げています。
- 拒否リスト型のサンドボックス: 「原則許可・危険なものだけ禁止」という設計は、OSの複雑さに追随しきれない。禁止し忘れた操作が抜け道になる。
- 実行可能な設定ファイル:
.vscodeのタスクや.claudeのフック、仮想環境のインタープリタ指定は、実質的に「実行されるコード」。エージェントが書き、箱の外の部品が信じて走らせる。 - コマンド名だけを見た許可リスト: 呼び出し全体ではなく名前で安全判定する方式の危うさ。
git showは「読み取り専用だから安全」とされたが、実際の呼び出しはファイルを書けた。 - 特権を持つローカル常駐プロセス: Docker Desktopのような常駐サービスはサンドボックスの外にいる。そこへ到達できれば、隔離の外でコードを実行する足場になる。
どのツールに何が見つかったか
各社はすでに修正を出しています。CVE番号は付与済みのものと採番待ちのものが混在します。
| ツール | 問題の要点 | 対応状況 |
|---|---|---|
| Cursor | .claudeフック設定を経由した非隔離のコマンド実行 | v3.0で修正（CVE-2026-48124 / GHSA-pc9j-3qc2-95wv） |
| Cursor | 改変した仮想環境インタープリタの実行 | 修正済み（GHSA-p9g2-cr55-cw9c） |
| Cursor | Gitメタデータ（fsmonitor）を悪用した回り込み | v3.0で修正・CVE採番待ち |
| Codex CLI | コマンド名だけを信頼するGit許可リストの回避 | v0.95.0で修正・高深刻度の報奨金・CVE採番待ち |
| Cursor / Codex / Gemini CLI | Dockerソケット到達による特権コンテナ起動 | 修正済み（GHSA-v4xv-rqh3-w9mc） |
| Antigravity | Seatbelt拒否リストの回避、VSCodeタスクの時限実行 | 「有効な脆弱性」と認定も深刻度は引き下げ |
1つのDockerソケットの問題がCursor・Codex・Gemini CLIの3つを同時に貫いた点は象徴的です。エージェント固有のバグというより、共通の土台にある構造的な穴だからです。GoogleはAntigravityの2件を「その他の有効な脆弱性」と認めつつ、悪用には利用者が悪意あるリポジトリを信頼するなどの社会工学が必要だとして深刻度を下げました。研究の質そのものは「卓越している」と評価しています。
これまでと何が変わるか
ポイントは、いずれも「サンドボックスの実装ミス」ではなく、サンドボックスという発想の限界を突いている点です。エージェントを箱に入れても、その箱が書き出したファイルを箱の外の道具（Python拡張、Git連携、VS Code、Docker、フック機構）が無条件に信頼する限り、実行はいつでも外へ漏れ出します。プロセス隔離だけを頼りにした「動かしているから安全」という安心は、そのまま通用しなくなります。開発者の端末は、従来型のプロセス分離ではなく、エージェント特有の脅威モデルで見直す段階に入りました。
いま現場で打てる手
Pillarは多層の防御を勧めています。運用にそのまま落とすなら、次のあたりが要点です。
- まずツールを最新版へ: Cursorはv3.0以降、Codex CLIはv0.95.0以降に更新する。修正はすでに配布されている。
- 設定ファイルの自動採用をやめる: フックやタスク、インタープリタ指定など「実行につながる設定」をエージェントが書き換えたら、人の明示的な承認を挟む。
- 直接実行と“お手伝いプロセス”に同じ規則を: エージェント自身の実行だけでなく、ホスト側の補助ツールが走らせる処理にも同一のポリシーを適用する。
- ファイルの出所を追う: 「人が書いた／エージェントが書いた／リポジトリ由来」を区別し、信頼の受け渡しが起きる箇所を監視する。
- Docker等の特権デーモンへの到達を絞る: 常駐サービスのソケットにエージェントが届く経路を見直す。
導入や評価の際に、ベンダーへ問うべき質問も具体的です。「エージェントはどのファイルを書けるのか」「そのファイルを自動実行するホスト部品はどれか」「到達可能なローカルデーモンは何か」「コマンド許可は名前で判定しているのか、実際の呼び出しで判定しているのか」。答えられない相手に、無人で回すエージェントを預けるのは早計でしょう。
利便性の裏で増える攻撃面
コーディングエージェントが「読んで、書いて、実行する」範囲を広げるほど、間接的なプロンプトインジェクションを起点に、開発者の手元で意図しないコードが走る余地も広がります。今回の各社の対応は迅速でしたが、より本質的なのは「エージェントが書いたものを、外の道具がどこまで信じてよいのか」という線引きが、まだ業界共通の作法として固まっていないことです。便利さと引き換えに攻撃面が増えるという指摘は、煽りではなく、無人運用を進める現場が正面から向き合うべき前提になりつつあります。
参照: The Week of Sandbox Escapes（Pillar Security） ／ BleepingComputer ／ Techzine ／ The Next Web ／ DevOps.com
