For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/ja/articles/openai-codex-security-issues-curated-plug-d8ba6dc7.md.
OpenAIはCodex SecurityとPatch the Planetを通じてAIによるソフトウェア脆弱性の発見を進めています。一方で、Codex自体もプラグイン同期、サンドボックス、ソフトウェアサプライチェーンに関する問題に直面してきました。本ガイドでは、確認済みのインシ...
OpenAIは2026年に入り、AIをソフトウェアセキュリティの領域へさらに深く導入してきました。
3月には、脆弱性の発見、検証、修正支援を目的とするアプリケーションセキュリティエージェント、Codex Securityをリサーチプレビューとして公開しました。6月には、Trail of Bitsと共同で、オープンソースのメンテナーがセキュリティ問題を発見して修正できるよう支援するDaybreakの取り組み、Patch the Planetを開始しました。7月末には、オープンソースのCodex Security CLIとTypeScript SDKもリリースしています。
そのため、Codexをめぐるセキュリティの動向は、非常に重要な意味を持ちます。
Codexは単なるコード生成モデルではありません。ローカル環境とクラウドに接続されたコーディングエージェントであり、リポジトリの読み取り、ファイルの編集、ツールの呼び出し、コマンドの実行、プラグインの読み込み、MCPサービスへの接続が可能です。また、ソースコードや認証情報が存在することの多い開発環境内で動作します。
9月には、BAAI／New智元の報道が、360 Tulongfengに帰属する新たなCodexのセキュリティに関する主張を取り上げました。報道によると、この問題はCodexのキュレーション済みGitプラグイン同期経路に関係し、機密性の高い操作の前にユーザーが通常期待する承認境界を回避できる可能性があるとされています。
ただし、この360による新たな発見については、OpenAIによる公開アドバイザリや、別個のゼロデイであることを独立して証明する詳細な技術報告書は、現時点で公開されていません。一方で、記事で説明されているより広範なリスクは現実のものです。公開済みのCodexの問題報告では、キュレーション済みプラグインの起動時同期がモデルのサンドボックス外で実行される可能性や、特定のGit環境下でプラグインキャッシュではなくユーザーのリポジトリを操作する可能性がすでに示されていました。
この違いは重要です。本記事では元のストーリー構成を維持しつつ、公開情報で確認されたインシデント、研究者が報告した発見、ベンダーに帰属する主張を分けて説明します。
OpenAIは2026年3月6日にCodex Securityを発表しました。
この製品は、コードベースのコンテキストを構築し、セキュリティ上の弱点を特定し、発見内容が意味のあるものかを検証し、修正案を提示するよう設計されています。単純なパターンスキャナーとは異なり、OpenAIはプロジェクト全体を横断して推論し、誤検知を減らせるエージェント型のセキュリティシステムとして位置づけています。
その後、OpenAIはPatch the Planetによってこの取り組みを拡大しました。
この取り組みでは、AIを活用した脆弱性調査と人によるレビューを組み合わせ、メンテナーが検証済みの発見内容を受け取り、パッチやテストを伴う形で対応できるようにします。
根底にあるメッセージは明確です。AIによってソフトウェアの開発速度と脆弱性の発見速度の両方が高まるため、防御側のチームにはコードをより速くレビューし、修正する方法が必要になります。
元の記事が指摘する皮肉は、他者のバグを発見するために使われているものと同種のコーディングエージェント基盤が、セキュリティ研究者にとって価値の高い標的にもなっていることです。
元の記事は、新たに発見されたCodexの脆弱性を360のTulongfengシステムによるものとし、その問題がCodexのキュレーション済みGitプラグイン同期メカニズムに関係していると説明しています。
通常の利用では、Codexは複数のセキュリティ制御に依存しています。
リスクが生じるのは、起動処理やインフラストラクチャのコードが、モデルが指示したコマンドに使われるものと同じサンドボックスの外側で実行される場合です。
この違いは、公開済みのCodexの問題報告にもすでに表れています。
7月に公開されたGitHubの問題報告では、キュレーション済みプラグインの起動時同期が、リポジトリ固有のGIT_*環境変数を完全に分離しないままGitコマンドを起動する事例が記録されました。Codexが特定のGitフックやワークツリーのコンテキスト内で起動された場合、同期処理が意図されたプラグインキャッシュではなくユーザーのリポジトリに対して動作する可能性がありました。
報告者は、同期処理がCodexの起動処理であり、サンドボックス内でモデルが実行するコマンドではなかったため、--sandbox read-onlyではこの動作を封じ込められなかったと具体的に指摘しています。
OpenAIは2026年6月24日、**「Isolate curated plugin sync Git environment」**という修正をmainブランチに取り込みました。影響を受けた0.142.xおよび初期の0.143ビルドをめぐる公開問題では、この修正が安定版リリースに反映される前に、まずmainに存在していたことが示されています。
この公開履歴は、記事の大きな論点を裏付けています。エージェントのセキュリティ境界は、モデルが直接要求するシェルコマンドだけでなく、エージェント自身のインフラストラクチャにも及ばなければなりません。
一方、Tulongfengに帰属する9月の主張が、以前から公開されていた起動時同期の分離問題とは別の攻撃経路なのかは、まだ明確ではありません。OpenAIまたは360による公開アドバイザリ、CVE、技術報告書がないため、本稿ではこの「新たなゼロデイ」という主張を、独立して立証された事実としては扱いません。
Codexにおける一般的な安全モデルは、次のようなものです。
OpenAIの現在のエージェントセキュリティガイダンスも、同じ広い原則に従っています。高リスクの副作用は独立して制限し、必要に応じて明示的な人によるレビューのために停止すべきだという考え方です。
問題は、権限プロンプトが操作を保護できるのは、その操作が実際にプロンプトを適用するコード経路を通過する場合だけだということです。
バックグラウンドアップデーター、プラグイン同期機能、ヘルパープロセス、その他の信頼されたサブシステムがその経路の外側で処理を実行すると、表示される承認インターフェースは、実際に有効なセキュリティ境界ではない可能性があります。
これは、2026年に報告されたCodexの脆弱性から得られる最も重要な教訓の一つです。
AIコーディングツールの脅威モデルは、もはや次の問いだけではありません。
「モデルは危険なコマンドの実行を要求するだろうか？」
さらに、次の問いも必要です。
「エージェントプラットフォームのどの部分が、モデルの通常の承認フローの前または外側で、ファイルを変更し、プロセスを起動し、コードを取得し、プラグインを読み込み、認証情報を読み取り、Gitとやり取りできるのか？」
元の記事は、ソフトウェアサプライチェーンへの影響を想定したシナリオで説明しています。
この連鎖では、明らかに悪意のあるダウンロードを経由してマルウェアが侵入する必要はありません。
より現実的な流れは次のとおりです。
これが、開発者のワークステーションが価値の高い標的になる理由です。
そこには次のような情報が存在する可能性があります。
最初に侵害されたマシンが、攻撃者の本当の目的とは限りません。
目的は、その開発者の身元とリリースパイプラインに付随する信頼である可能性があります。
これがサプライチェーンリスクの本質です。攻撃者は、信頼されたソフトウェア経路を配布メカニズムへと変えようとします。
キュレーション済みプラグインの問題は、AIコーディングエージェントをめぐるセキュリティ研究の広い流れの一部です。
元の記事は複数の2026年のインシデントをまとめて扱っており、その多くは独立して検証できます。
Pwn2Own Berlin 2026では、OpenAI Codex、Anthropic Claude Code、Cursorを標的とする専用のCoding Agentカテゴリーが新設されました。
Zero Day Initiativeの公式初日結果によると、Compass SecurityはCWE-150の問題を利用してOpenAI Codexの攻略に成功し、40,000ドルとMaster of Pwnポイント4点を獲得しました。
DoyensecもCodexに対するエクスプロイトを実演しましたが、ベンダーが基礎となるバグをすでに把握していたため、結果は**衝突（collision）**に分類されました。
イベント全体では、すべてのカテゴリーを通じて47件の固有のゼロデイ脆弱性と、総額1,298,250ドルの賞金が記録されました。
Pwn2Ownが特に参考になるのは、コーディングエージェントのルールで、単純なジェイルブレイクや安全でないモードが除外されていたためです。成功したエントリーは、一般的なコーディングエージェントのワークフローを通じて、意味のあるセキュリティ境界を越えなければなりませんでした。
8月12日、360は、同社のTulongfeng AIセキュリティシステムがOpenAI Codexの高価値なセキュリティ脆弱性を6件発見したと公表しました。
360の発表によると、発見内容には、リモートでの任意コード実行につながる可能性がある高リスク事例や、ユーザーが信頼できないプロジェクトディレクトリを開いた際にCodexの信頼プロンプトを回避できる事例が含まれていました。
この開示内容は複数の中国メディアと、シンジケーション記事を通じた新華社によって報じられました。
ただし、本記事の調査対象となった情報源では、6件すべての詳細な技術報告書やCVE形式の識別子は公開されていませんでした。
したがって、この主張を正確に表現するなら、次のようになります。
360は、Tulongfengが6件の高価値なCodex脆弱性を発見し、その中にはリモートコード実行の影響を伴う事例が含まれていたと報告している。
これは、公開された技術資料に基づいて6件すべてのエクスプロイトチェーンを独立検証したこととは異なります。
Accomplishのセキュリティ研究者Oren Yomtovは、8月12日にCodexのサンドボックス脱出を2件、OpenAIへ報告しました。
研究者はこれらをOverpatchとHeapjackと名付けました。
OverpatchはオープンソースのCodex CLIのパッチ適用経路に影響し、意図されたworkspace-writeの境界から脱出できる可能性がありました。
HeapjackはCodex Desktopが使用するJavaScriptヘルパーを標的とし、研究者によれば、Codexが読み取り専用モードで動作している場合でも、最終的にサンドボックス外でのコマンド実行につながる可能性がありました。
研究者は、OpenAIが両方の問題を8日以内に修正したと述べています。
公開された修正案内によると、ユーザーは次のバージョン以降へ更新する必要があります。
| 問題 | 研究者が報告した修正版 |
|---|---|
| Overpatch | Codex CLI 0.149.0以降 |
| Heapjack | Codex Desktopビルド26.818.21641以降 |
これらのバージョン番号は、別途発行されたOpenAIのセキュリティアドバイザリではなく、研究者による開示情報に基づくものです。
AIR Securityは9月17日、Plugin4Shellを開示しました。
この脆弱性は、次の製品におけるプラグインのインストールおよび更新ロジックに影響しました。
AIRによると、これはプラグインのインストール後にチェックアウトされたコードが、マーケットプレイスが固定しようとしたコミットと一致することを検証できていなかったことに起因する、ゼロクリックのリモートコード実行経路でした。
CodexとClaude Codeはインストール済みプラグインを自動更新できたため、ユーザーが新たにクリックしなくても、以前は信頼されていたプラグインがサプライチェーンの経路になる可能性がありました。
AIRは、OpenAIが0.146.0でCodexを修正したと述べています。
Plugin4Shellが重要なのは、モデルの挙動の失敗ではなかったためです。これは、エージェントを取り巻く配布レイヤーにおける、典型的なソフトウェアサプライチェーン設計上の欠陥でした。
2026年に報告されたCodexの問題は、すべてが一つの根本原因を共有しているわけではありません。
サンドボックス境界に関係するものもあります。
ヘルパープロセスに関係するものもあります。
Git環境の処理に関係するものもあります。
プラグイン配布に関係するものもあります。
しかし、いずれも拡大した信頼コンピューティングベースを共有しています。
現代のコーディングエージェントは、単純な次の構造ではありません。
ユーザーのプロンプト -> モデル -> 回答
実際には、次の構造に近いものです。
ユーザー
-> モデル
-> エージェントハーネス
-> ツールルーター
-> シェル
-> ファイルシステム
-> Git
-> プラグインマネージャー
-> MCPサービス
-> 認証情報
-> ネットワーク
-> CI/CD
各レイヤーは有用な機能をもたらします。
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
同時に、各レイヤーが新たなセキュリティ境界を生み出す可能性もあります。
だからこそ、「モデルはサンドボックス化されている」という説明だけでは、完全なセキュリティ上の根拠にはなりません。
エージェントプラットフォームは、アップデーター、プラグインローダー、ファイルエディター、ターミナルブリッジ、ネットワークプロキシ、ヘルパーデーモン、認証情報の経路も、同じセキュリティ前提に従っていることを示さなければなりません。
元の記事のより大きな論点は、AIがソフトウェアセキュリティの両側を加速していることです。
開発側では、コーディングエージェントが、従来の手作業中心のワークフローよりもはるかに速く、機能、テスト、インフラストラクチャ、連携、さらにはプロジェクト全体を作成できます。
これにより、新しく作られるコードの量が増加します。
防御側では、Codex SecurityやTulongfengのようなシステムが、大規模なコードベースを分析し、機械的な規模で脆弱性を発見するよう設計されています。
これにより、既存および新規の脆弱性が発見される速度が高まります。
この2つの傾向は互いに作用します。
コードが増えれば、攻撃対象領域も増えます。
セキュリティ自動化が向上すれば、その攻撃対象領域のより多くを発見できるようになります。
その結果、ソフトウェアエコシステムが必ずしも安全でなくなるとは限りません。しかし、セキュリティレビューはAI支援開発の速度に近いペースで動作する必要があることを意味します。
コーディングエージェントは、ソフトウェアスタックの中で独特な位置にあります。
ユーザーが最終的にインストールするアプリケーションよりも上流に位置しています。
次のような情報や機能にアクセスできる場合があります。
通常のチャットボットにおける失敗は、誤った回答を生成する可能性があります。
コーディングエージェントの失敗は、変更されたファイル、起動されたプロセス、変更されたリポジトリ、漏えいした認証情報、侵害されたビルド経路を生み出す可能性があります。
そのため、コーディングエージェントのセキュリティは、モデルの安全性だけでなく、エンドポイントセキュリティやソフトウェアサプライチェーンセキュリティにも近づいています。
OpenAI自身の現在のサンドボックスガイダンスも、この現実を反映しています。ワークロードの分離、外向きネットワークアクセスの制限、認証情報の分離、エージェント実行環境の外部でのアプリケーションキーの管理、重要な操作に対する独立した承認制御が推奨されています。
元の記事の最後の3分の1は、360 Tulongfengと、防御側と攻撃側の競争に焦点を当てています。
中心となる考え方は有効です。脆弱性は、ベンダーが把握しているかどうかにかかわらず存在します。
防御側が先に発見すれば、悪用が広がる前にシステムを修正できる可能性があります。
攻撃者が先に発見すれば、同じバグがインシデントになる可能性があります。
これが、自動化された脆弱性調査の経済的な意義です。
OpenAIのCodex SecurityとPatch the Planetの取り組みも、組織は異なりますが、同じ前提に基づいています。
目標は、ソフトウェアライフサイクルのより早い段階へ脆弱性の発見を移すことです。
360は、Tulongfengを次の2つの要素を中心に構成されたAI脆弱性発見システムとして説明しています。
360によると、この製品はソースコード、バイナリ、ファームウェア、業務システム、AIツールチェーンのテストに使われています。
同社はまた、Tulongfengが2026年8月末から9月にかけて、1万件を超える脆弱性を発見したと述べています。
この合計値は、ベンダーが報告した累積数です。
8月25日の360コミュニティ発表では、システムが1万件を超える脆弱性を発見し、約400組織が接続してセキュリティテストを完了したと説明されました。その後の9月の投稿でも、1万件超という数字が繰り返されています。
元の記事はさらに、260件の発見内容が中国の脆弱性当局によって検証され、約500組織が接続したと主張しています。しかし、本稿向けに確認した最新の360の情報源では、これらの正確な数字を照合できなかったため、独立して確認された数値としては繰り返しません。
元の記事は、Tulongfengのアプローチを再帰的な改善の一形態として説明しています。
この概念は、基盤モデルが自身の重みを書き換えるというより、完了したセキュリティタスクから再利用可能な運用上の記憶を構築することに近いものです。
ワークフローは次のように要約できます。
これは、セキュリティチームがプレイブック、エクスプロイトの知識ベース、検知ルール、インシデント対応手順を構築する方法に似ています。
違いは、エージェントシステムがその経験をはるかに高速に、しかも多数の並列タスクにまたがって再利用できる可能性があることです。
ベンダーの主張は、これによって個々のセキュリティ上の発見が、エージェント群全体で共有される能力になるというものです。
記事は、維持する価値のあるサプライチェーンのイメージで締めくくられています。
ユーザーが「更新」をタップするとき、そのソフトウェアは次の経路を通過している可能性があります。
各段階は、その前の段階から信頼を引き継ぎます。
AIコーディングエージェントは、現在この連鎖の初期段階に位置しています。
そのため、AIコーディングエージェント自体のセキュリティ制御は、エージェントが作成・出荷を支援するすべてのアプリケーションのセキュリティモデルの一部になります。
実践的な教訓は、開発者がコーディングエージェントの利用をやめるべきだということではありません。
コーディングエージェントを、強力な開発インフラストラクチャとして扱う必要があるということです。
他の特権的なツールと同様に、バージョン管理、分離、最小権限、シークレットの分離、プラグインガバナンス、セキュリティ監視、迅速なパッチ適用が必要です。
OpenAIの現在のガイダンスと、2026年に公開された脆弱性情報に基づくと、開発者は具体的な対策によってリスクを低減できます。
既知のセキュリティ修正は急速に提供されています。
上記で扱った研究者開示の問題については、影響を受けるユーザーはPlugin4Shell、Overpatch、Heapjackについて報告された修正版ビルドより新しいバージョンを使用する必要があります。
「エージェントに質問しただけ」だからコードパスが実行されないと考えてはいけません。
見慣れないリポジトリを確認する際は、分離環境を使用してください。
高価値なクラウド、パッケージレジストリ、署名、本番環境の認証情報を、エージェントの実行環境に直接公開することは避けてください。
タスクに必要な外向き通信先だけを許可してください。
任意の外向き通信と広範な認証情報を持つコーディングエージェントは、被害範囲が大幅に広がります。
信頼されたエージェントでも、信頼できない拡張機能や更新経路を通じて侵害される可能性があります。
プラグインは意図的に固定、監査、更新してください。
影響の大きい操作については、承認をエージェントと同じ実行環境内で動くロジックだけに任せず、別の信頼されたコンポーネントによって強制すべきです。
次の項目を記録し、確認してください。
エージェントが行ったことの一部は、モデルの最終回答にすぎません。
Codexは、Gitを通じてキュレーション済みプラグインを同期する起動メカニズムを使用してきました。公開されたGitHubの問題報告では、以前のバージョンがリポジトリ固有のGit環境状態を引き継ぎ、読み取り専用サンドボックスの外側で、意図されたプラグインキャッシュではなくユーザーのリポジトリに対して同期処理を実行する可能性が示されました。
BAAI／New智元の記事は、新たなキュレーション済みGit同期攻撃経路を360 Tulongfengによるものとしています。しかし、この9月の主張が別個の新しいゼロデイであることを独立して立証する公開OpenAIアドバイザリや、360による詳細な技術開示は確認されていません。そのため、完全に検証された公開発見ではなく、帰属付きの報道として扱うべきです。
Accomplishの研究者Oren Yomtovが開示した、Codexのサンドボックス脱出問題です。研究者によると、両方とも8月12日にOpenAIへ報告され、8日以内に修正されました。
Plugin4Shellは、AIR Securityが2026年9月17日に開示したプラグインサプライチェーンの脆弱性です。AIRによると、Claude Code、Codex、GitHub Copilot、Gemini CLIに影響し、インストールされたプラグインがマーケットプレイスが固定しようとしたコミットと一致するという保証を破壊しました。
はい。Zero Day Initiativeは、初日にCompass SecurityがCodexの攻略に成功し、3日目にはIkotas Labsも別のCodex攻略に成功したと報告しています。Doyensecもエクスプロイトを実演しましたが、ベンダーが基礎となるバグをすでに把握していたため、衝突として分類されました。
OpenAIは2026年7月、Codex Security CLIとTypeScript SDKをオープンソースソフトウェアとして公開しました。ただし、一部のサイバーセキュリティ機能や保護された発見内容へのアクセスには、適切なOpenAIアクセス権限またはTrusted Access for Cyberが必要になる場合があります。
どのモードも絶対的な保証として扱うべきではありません。2026年に報告された複数の問題は、脆弱なコンポーネントが想定されたモデルサンドボックスの外側で動作したり、意図されたセキュリティ境界を越えたりしたことが特に重要でした。
最新バージョンを使用し、信頼できないコードを分離し、ネットワークアクセスを制限し、長期間有効な認証情報を実行環境の外部に保管し、プラグインを監査し、重要な操作には独立した人による承認を使い、エージェントが実際に行ったツール操作とシステム活動を記録してください。
OpenAIはCodex SecurityとPatch the Planetを通じて、防御目的の脆弱性調査を加速しています。しかしCodex自体も、ソースコード、ツール、認証情報、プラグイン、ソフトウェアのリリースワークフローに近い位置にあるため、ますます重要なセキュリティ標的になっています。
2026年に公開情報で確認されたインシデントには、Pwn2OwnにおけるCodexの攻略、キュレーション済みプラグインの起動時同期に関する分離バグ、OverpatchとHeapjackのサンドボックス脱出、Plugin4Shellが含まれます。360 Tulongfengに帰属する9月の「新たなゼロデイ」については、以前のプラグイン同期問題とどのように異なるのかを詳細な公開アドバイザリが示すまで、より慎重に扱うべきです。
これらすべての事例に共通する大きな教訓は、AIコーディングエージェントのセキュリティ境界がモデルだけに限定されないということです。アップデーター、プラグインマネージャー、Git連携、ツールランタイム、ヘルパープロセス、ネットワークアクセス、認証情報の処理、承認システムのすべてが、信頼コンピューティングベースの一部になります。
AIコーディングツールは、今や上流のソフトウェアインフラストラクチャです。そのセキュリティ制御は、構築や出荷を支援するアプリケーションおよびサプライチェーンと同じ厳格さで扱う必要があります。
ひとことから始めて、数分で完全なサイトを手に入れましょう。
