OpenAI Codexのサンドボックス迂回をZDIがゼロデイとして公開

TL;DR

---

Trend MicroのZero Day Initiativeが、OpenAI Codexのサンドボックス迂回脆弱性をZDI-26-305として公開した。
窓の杜も「Codex」にサンドボックス迂回のゼロデイ脆弱性として取り上げている。

ZDIの説明では、問題はCodexのJavaScript実行環境にある。
サンドボックス化されたコンテキストの隔離が不十分で、悪意あるJavaScriptを含むリポジトリをCodexに処理させると、攻撃者がサンドボックスを越えて現在のユーザー権限でコードを実行できる、という内容だ。

CVSSは8.6。
ベクトルは AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H で、ローカル攻撃扱いだがユーザー操作あり、スコープ変更あり、機密性・完全性・可用性がすべて高影響になっている。

未信頼リポジトリを読ませるだけで境界が崩れる

今回の条件は「標的ユーザーがCodexで悪意あるJavaScript入りリポジトリを処理すること」だ。
Webブラウザのドライブバイ攻撃のように勝手に発火する話ではない。

ただ、AIコーディングエージェントではこの条件がかなり現実的になる。
「このOSSを調べて」「このPRをレビューして」「この再現リポジトリで落ちる原因を見て」と投げる作業そのものが、未信頼コードをエージェントの実行環境へ入れる行為だからだ。

Codexのサンドボックスは、本来このリスクを受け止める境界として説明されている。
OpenAIの公式ドキュメントでも、サンドボックスはCodexがローカルコマンドを実行するときにフルアクセスではなく制約付き環境で動かすための境界であり、ファイル変更やネットワーク利用の可否を定義するものだと説明している。

だから今回の焦点は、「危ないコードを実行したら危ない」ではなく、危ないコードを扱うための境界がJavaScript実行環境の分離不備で破れるという点にある。

OpenAIは再現確認後に対象外扱い

ZDIのタイムラインはこうなっている。

日付	内容
2026-02-24	ZDIがOpenAIへ報告
2026-02-25	OpenAIが受領を確認
2026-03-05	OpenAIが技術的な補足を要求
2026-03-09	ZDIが追加情報を提供
2026-04-06	OpenAIが再現可能と連絡
2026-04-13	OpenAIがバグ報奨金の対象外として却下
2026-04-13	ZDIが報奨金は不要として修正予定日を質問
2026-04-13	OpenAIが「デフォルトのCodex製品面ではない」と説明
2026-04-17	ZDIがゼロデイ公開の意向を通知
2026-04-28	ZDIが公開

ここで妙なのは、OpenAIが挙動の再現を確認しているのに、修正ではなくスコープ外という扱いになっている点だ。
ZDIの文面からは、具体的にどのCodex面が影響するのか、Codex CLIなのか、アプリなのか、クラウド側なのか、あるいは特定のJavaScript実行機能なのかまでは分からない。

OpenAI側の「デフォルトのCodex製品面ではない」という説明も、利用者から見ると曖昧だ。
デフォルトでない設定や機能を有効にしたユーザーだけが該当するのか、内部的な非公開面の話なのか、公開されたZDIアドバイザリだけでは判定できない。

Codexはサンドボックス前提で信頼を組んでいる

Codex CLIの設計は、以前書いたAIコーディングCLIのHooks機能比較でも触れた通り、Hooksで任意処理を差し込むより、承認ポリシーとOSレベルサンドボックスで行動を縛る方向に寄っている。
macOSはSeatbelt、Linuxはbubblewrapやseccomp、WindowsはWSL2やWindowsネイティブのサンドボックス実装を使う、という思想だ。

OpenAIの現在のドキュメントでも、workspace-write ではネットワークアクセスやワークスペース外編集に承認が必要で、danger-full-access や --dangerously-bypass-approvals-and-sandbox は注意して使うべきものとして扱われている。
外側の強制境界があるから、エージェントにある程度自律的にコマンドを実行させられる。

その境界の一部がJavaScript実行環境で抜けるなら、設定画面やCLIフラグ上は安全そうに見えても、実際の危険度は変わる。
特に --ask-for-approval never と組み合わせて長時間走らせる運用では、人間が異常なコマンドを目で止める機会も少ない。

以前のCodex脆弱性とは攻撃面が違う

3月末にも、OpenAI Codexではブランチ名のコマンドインジェクションでGitHubトークンを窃取できた件が公開されていた。
この件はClaude Codeのソースコード全公開とOpenAI Codexのトークン窃取脆弱性にまとめている。

前回は、ブランチ名という入力がシェルコマンドに渡る経路のサニタイズ不備だった。
今回のZDI-26-305は、JavaScript実行環境内のサンドボックスコンテキスト分離が問題とされている。
どちらも「未信頼リポジトリをエージェントが処理する」点では同じだが、壊れている層が違う。

flowchart TD
    A[未信頼リポジトリ] --> B[Codexが解析・実行]
    B --> C{攻撃面}
    C --> D[ブランチ名などの入力処理]
    C --> E[JavaScript実行環境]
    D --> F[コマンド注入<br/>GitHubトークン窃取]
    E --> G[サンドボックス迂回<br/>ユーザー権限で実行]

この違いは運用上も効く。
入力サニタイズ系なら「怪しいブランチ名を拒否する」「タスク作成APIの引数を検証する」といった局所的な修正ができる。
サンドボックスコンテキストの隔離不備は、実行環境そのものの境界を見直す話になる。

いま取れる対策は外側の隔離しかない

ZDIは緩和策として、製品とのやり取りを制限することだけを挙げている。
パッチ、設定変更、検出ルール、影響バージョンの情報は出ていない。

Codexを使い続けるなら、最低限このあたりに寄せる。

対策	効く範囲
未信頼リポジトリをCodexに読ませない	今回の前提条件を潰す
danger-full-access を避ける	サンドボックス外での被害範囲を広げない
--ask-for-approval never を未信頼コードで使わない	異常な実行を人間が止める余地を残す
Dev ContainerやVMの内側でCodexを動かす	Codexの内側の境界が破れてもホストへ直通させない
コンテナ内にSSH鍵やクラウド認証情報を置かない	ユーザー権限で実行された後の窃取対象を減らす
ネットワークを許可リスト化する	外部送信や追加ペイロード（攻撃用コード）の取得を絞る

OpenAIのドキュメントにも、Dockerなどで外側の隔離境界を用意する場合でも、danger-full-access で動かすとコンテナ内のCodex認証情報などは盗まれうると書かれている。
つまり「コンテナなら安全」ではなく、「盗まれて困るものをコンテナ内に入れない」まで含めて設計する。

AIエージェントのローカル隔離実行、macOS sandbox-execとWindowsサンドボックスで何が違うかで書いた通り、AIエージェントの安全性はモデルの賢さではなく、プロセス・ファイルシステム・ネットワーク・認証情報の境界で決まる。
今回のように製品内のサンドボックス境界が未確定なら、外側にもう一段置くしかない。

分からないまま残っていること

現時点で分からない点も多い。

未確定点	コメント
影響するCodexの面	CLI、IDE拡張、アプリ、クラウド環境のどれかはZDI本文から断定できない
影響バージョン	アドバイザリにバージョン番号がない
PoCの有無	公開されていない
悪用事例	ZDI本文にも窓の杜記事にも実悪用の記載はない
OpenAIの修正予定	公開情報では未確認

Codex Securityは、脆弱性をサンドボックスで検証して誤検知を減らすという方向で提供されている。
以前のCodex SecurityがSASTレポートを出さない理由でも、その検証フェーズが売りになっていた。

その同じベンダーのコーディングエージェントで、サンドボックス境界に関する未パッチのゼロデイが出ている。

参考

• ZDI-26-305 | Zero Day Initiative
• OpenAIの「Codex」にサンドボックス迂回のゼロデイ脆弱性 ～Trend MicroのZDIが指摘 - 窓の杜
• Sandbox - Codex | OpenAI Developers
• Agent approvals & security - Codex | OpenAI Developers