2026年7月20日、BleepingComputer に Cursor, Codex, Gemini CLI, Antigravity hit by sandbox escapes という記事が出ました。
元ネタはセキュリティ企業 Pillar Security の研究チームで、Cursor・OpenAI Codex・Google Gemini CLI・Google Antigravity の4製品を対象に、サンドボックスの外へ「抜ける」手口を実証したものです。
数ヶ月かけて再現し、1日1本ずつ「The Week of Sandbox Escapes（サンドボックス脱出の一週間）」として公開したそうです。
技術的な肝は1つだけなので、そこさえ押さえれば十分です。日本語でかみ砕いて整理します。
3行でいうと
- AIコーディングツールの「サンドボックス（作業を隔離する箱）」が、4製品で抜けられた
- しかも箱を正面から破ってはいない。箱の中にファイルを置いただけで、箱の外の"信頼された道具"がそれを勝手に実行した
- 前提は「悪意あるリポジトリを信頼して開く」こと。ほとんどは修正済み
そもそもサンドボックスって？
AIエージェントにコードを書かせるとき、怖いのは「勝手に rm -rf されたら？」「秘密鍵を外に送信されたら？」という暴走ですよね。
そこで各ツールは、エージェントの手をプロジェクトのフォルダの中だけに縛る仕組みを持っています。これがサンドボックスです。すごく雑に言うと、「机の上（ワークスペース）では好きにやっていいけど、部屋の外（ホスト OS）には手を出すな」という囲いです。
理屈のうえでは、これでエージェントが何をやらかしてもプロジェクト内で完結する…はず。
今回の抜け方
研究者たちは、この囲いを力ずくで壊してはいません。エージェントは最後まで箱の中でルールを守っています。
やったのはこれだけ。
箱の中に「あるファイル」を置く。すると、箱の外にいる別の道具が、後からそのファイルを読んで・実行して・スキャンしてくれる。
ここがポイントで、ワークスペースの中のファイルは「ただのデータ」ではないわけです。
IDE の拡張機能、Git 連携、Python 拡張...etc。こうした「箱の外で動く道具」が、箱の中のファイルを信頼して読み込み、そのとおりに動く。だからエージェントが書き込める1個のファイルが、ホスト側で走る1個のコマンドに化けます。
料理でたとえると、キッチン（箱）からは一歩も出ていないのに、出前の伝票（設定ファイル）だけ書いておく。あとで配達員（箱の外の道具）が、その伝票どおりに動いてくれる、という感じです。エージェント自身は、指一本すら箱の外に出していません。
Pillar の結論が刺さります。ざっくり訳すと「エージェントに箱があるかどうかは問題じゃない。エージェントが書いたファイルの"行き先"を、後で誰が信じて実行するかが問題なのだ」と。
どこを突かれたのか（4つの型）
抜け方は、大きく4つのパターンに整理されています。
型1. 設定ファイルが、実質"実行可能コード"だった
エージェントが書ける設定ファイルが、実は「後で自動実行される手順書」だったパターン。
-
Cursor: ワークスペース内の
.claudeのフック設定を書けてしまい、それが箱の外でのコマンド実行につながった（CVE-2026-48124、v3.0.0 で修正）。他にも、Python 仮想環境（venv）のインタープリタを書き換えると、Python 拡張が起動時にそれを実行してしまう穴も見つかっています。 -
Antigravity:
.vscodeのタスク設定を書くと、ホストが後で「信頼された自動処理」として実行し、Secure Mode を回避できた。
型2. コマンドの"名前"だけ信じた許可リスト
「このコマンドは安全」と名前でホワイトリスト登録していたが、実際の呼び出し方までは見ていなかったパターン。
-
Codex:
git showを「読み取り専用だから安全」と名前で許可。ところがgit showはオプション次第で、ファイル書き込みも設定読み込みもフック実行もできてしまう。名前だけの許可は雑すぎた…という話です。（v0.95.0 で修正／高深刻度として報奨金が支給）
型3. 箱の外にいる"特権デーモン"に手が届いた
- Codex・Cursor・Gemini CLI（3つ同時に該当）: サンドボックスで直接のファイル書き込みは塞がれていたのに、Docker のソケットには触れた。Docker のデーモンはホスト権限で、エージェントの制限の外で動きます。つまりエージェントが Docker に「お願い」すれば、箱の外で処理が走ってしまいます。
型4. 「原則許可・個別禁止」方式の穴（Antigravity）
- Antigravity（macOS）: 「基本は許可、危ないものだけ個別に禁止」という denylist 型の Seatbelt プロファイルだった。OS の機能は膨大なので、禁止し忘れた穴から箱の外で実行できてしまいます。
もう一つ小ネタで、Cursor では Git の .git フォルダを監視する fsmonitor を悪用する手口も見つかっています。.git を標準じゃない場所に置くと、パス基準のサンドボックス規則がすり抜けてしまう…という細かい話です（v3.0.0 で修正）。
各ベンダーの対応
| 製品 | 主な内容 | 対応 |
|---|---|---|
| Cursor |
.claude フック・Python venv・fsmonitor 悪用 |
v3.0.0 で修正（CVE-2026-48124 ほか） |
| OpenAI Codex |
git show 許可リストの穴 |
v0.95.0 で修正・報奨金支給 |
| Gemini CLI | Docker ソケット経由（他2社と共通） | 修正済み |
| Antigravity | Seatbelt denylist・.vscode タスク |
Google は深刻度を格下げ（後述） |
Google だけ対応がやや冷ためで、Antigravity の2件を「有効な脆弱性ではあるが、悪用は難しい」として深刻度を下げました。研究の質そのものは評価しています。
で、私たちは何を怖がればいいの？
今回の攻撃、前提はそれなりに重いです。
- 攻撃者の悪意ある指示（プロンプトインジェクション）が、README・Issue・依存パッケージ・コードのコメント・差分などに仕込まれている。
- そのリポジトリを、あなたが信頼してエージェントに開かせる。
Google が「悪用は難しい」と言ったのも、この「ユーザーが罠リポジトリを信じ込む」というソーシャルエンジニアリング前提があるからで、的外れではありません。
セキュリティで最も脆弱なのは「人間自身」というのは、今も昔もそしてこれから先の未来も、変わることはありませんので。
ただし、軽視もできないと思います。理由は2つ。
- AIエージェントに「そのへんの GitHub リポジトリをクローンして直しといて」は、もう日常の作業です。信頼できない入力を食わせる機会は増える一方。
- そして今、多くの人が Karpathy の言う "Accept All"（差分を読まず全部承認）で回している。人間のレビューという最後の関門を自分で外していると、この手の「設定ファイルを1個置くだけ」の攻撃はきれいにぶっ刺さります。
対策
対策は地味です。
- ツールを最新版に上げる（Cursor 3.0.0 / Codex 0.95.0 以降）
- 信頼できないリポジトリをエージェントに丸投げしない
- 少なくとも設定ファイルや実行系の差分は、自分の目で見る
結論
「サンドボックスがあるから安全」。これは半分正しくて、半分は幻想です。
エージェントを箱に閉じ込めても、その箱の中に未来の指示書を書ける限り、箱の外の道具がそれを拾って実行してしまう。
囲いの高さより、「エージェントが残したファイルを、後で誰が信じるのか」のほうがずっと大事…というのが今回の教訓です。
とはいえ、これは「AIコーディングツールは危険だから使うな」という話ではありません。私自身、明日も Claude Code をぶん回します。
ただ、"箱に入れたから丸ごと任せて OK" という思い込みは、捨てましょう。今回の対象は4製品ですが、教訓自体はエージェント型ツール全般に効く話です。
一次ソース: Pillar Security「The Week of Sandbox Escapes」（2026-07-20）