JustFit
ブログ
Pwn2OwnでCodexとLiteLLMの脆弱性を実演

Pwn2OwnでCodexとLiteLLMの脆弱性を実演

2026.10.12 JustFit編集部（運営：株式会社LEGAREA）

この記事では、2026年10月6日に始まったセキュリティ競技会「Pwn2Own Ireland 2026」で、OpenAI CodexやLiteLLMなどのAI関連ツールの脆弱性が実演された内容を、主催者の公式ページをもとに整理します。あわせて、AIを使うシステムで新規事業を作るとき、何を見直したくなるかを、JustFit編集部の見方として書きます。

10月6日に始まった競技会で、AIツールが標的になった

Pwn2Own（パウンツーオウン）は、チームどうしが、これまで知られていなかった脆弱性（ソフトウェアの弱点）をどれだけ見つけられるかを競うハッキング競技会です。主催はZero Day Initiative（ZDI）で、今回はアイルランドのコークで開かれました。開催は10月6日に始まっています。

初日の対象について、スマートフォン、スマートホーム機器、プリンターに加えて、OpenAI CodexやLiteLLMといったAIツールが狙われたと報じられています。ZDIの公式スケジュールを見ると、OpenAI Codexは「Coding Agent（コーディングエージェント）」というカテゴリで挑戦対象になっています。LiteLLMは「AI Infrastructure（AI基盤）」のカテゴリです。複数の報道では、このAI基盤のカテゴリが今回初めて設けられたとされています。

ここで出てくる言葉を、先に短く説明します。

ゼロデイ：開発元が修正を用意する前に見つかった弱点のことです。
コーディングエージェント：指示を受けて、コードを書いたり、コマンドを実行したりするAIのことです。
LiteLLM：複数のAIモデルを、ひとつの窓口から呼び出せるようにする基盤（ゲートウェイ）として使われるソフトウェアです。

公式の結果ページで確認できたこと

ここでは、ZDIの公式ブログに書かれていることだけを取り上げます。

1日目（10月6日）

1日目は21件の挑戦が行われました。AIに関係するものは次の通りです。

LiteLLM：Xintのチームが、入力の検証が不十分な点とコードインジェクションを組み合わせ、リバースシェル（外部から操作できる接続）を得ました。
LiteLLM（別チーム）：Out of Boundsのチームも成功しましたが、4つの不具合のうち2つはすでに知られたものでした（ZDIの区分では「衝突」）。
OpenAI Codex：Ikotas Labsが、1件の引数インジェクションの不具合を使ってOpenAI Codexを攻略しました。
Oracle Autonomous AI Database：VinSOCのチームが5つの不具合を組み合わせて攻略しました。

引数インジェクションとは、あるソフトが別のプログラムに値を渡すとき、その値の扱いが不十分だと、渡した側の意図と違う動きをさせられてしまう弱点です。AI特有というより、ソフトウェア開発で昔から知られている種類の弱点です。

2日目・3日目（10月7日〜8日）

2日目の公式ページでは、Out of BoundsのHaeJung Yang氏が、AI基盤カテゴリで「Dynamo」を攻略したと記されています。報道によれば、これはNVIDIAの推論フレームワークです。同じページには、AI基盤カテゴリのChromaに挑んだ最後の挑戦が、時間切れで失敗したという記録もあります。ChromaはAI向けのデータベース（ベクトルデータベース）として知られています。

3日目も、Oracle Autonomous AI Databaseへの挑戦が2件、Chromaへの挑戦が1件、予定されていました。そのうちOracleでは、OtterSecのチームが、4つの不具合のうち3つが衝突、1つがゼロデイという組み合わせで成功しています。

公式ページに書かれていないこと

初日の報告について、ZDIは不具合の種類は示したものの、詳しい攻撃の手順、影響を受けるバージョン、CVE番号（脆弱性の識別番号）は公開していないと報じられています。また、Pwn2Ownでは、修正のために開発元へ90日間の猶予が与えられ、その後に詳細が公開されるという仕組みだと説明されています。

今回調べた範囲では、OpenAIやLiteLLMの保守担当による修正状況の公式発表は確認できませんでした。そのため、「すでに修正済みかどうか」「利用者側で何かが必要かどうか」は、この記事では判断できません。各ツールの公式の案内を確認する必要があります。なお、競技の総賞金額などは報道によって数字が異なるため、ここでは書いていません。

私たちの見方：AIを組み込んだシステムでも、弱点の入口は従来と近い

ここからは事実ではなく、JustFit編集部の見方です。

見方1：AIを入れても、確認する場所は「ふつうのソフト」と同じところに残る

今回、複数の報道が指摘しているのは、Codexの件は新しい種類の弱点ではなく、シェルコマンドへの引数インジェクションは古くから知られているという点です。LiteLLMの件も、ZDIの記述は入力検証の不備とコードインジェクションで、ソフトウェアの基本的な弱点です。

私たちは、これを「AIが危ない」という話としては受け取っていません。むしろ、AIを使ったサービスも、入力の扱い、外部への命令の渡し方、権限の切り方といった、ふつうのシステム開発の確認項目から逃れられない、という確認になったと考えています。

見方2：AIモデルへの窓口やAI用データベースも、構成図に書いておく

AIを組み込んだ新規事業では、画面と業務ロジックのほかに、複数のAIモデルへの窓口（LiteLLMのような基盤）や、検索用のAIデータベース（Chromaのようなもの）が加わることがあります。今回のAI基盤カテゴリの結果は、こうした部品が、競技会で狙われる対象として扱われたことを示しています。

試作の段階では、動くことを優先して部品を足していくことが多いはずです。ただ、どの部品が外部からの入力を受け取り、どの部品が社内のデータに触れるのかを、構成図に書いておくだけでも、後の確認はしやすくなります。

見方3：開発に使うAIツールも、手元の環境の一部として扱う

コーディングエージェントについて、報道では、ファイルや開発環境、コマンド実行ツールなどに触れながら作業すると説明されています。つまり、開発を速くするための道具が、ソースコードや認証情報の近くで動くことになります。

AIに開発を進めてもらうこと自体を、否定する理由にはなりません。ただ、AIが動く環境に何を置くか、どのリポジトリを読み込ませるか、外から取り込んだフォルダをそのまま開いてよいか、といった運用は、事前に決めておく価値があります。関連して、AI生成コードのセキュリティの確認点や、AIエージェントの動ける範囲を仕様として決める話も参考になります。

見方4：試作と、お客様に公開する前とで、確認の深さを分ける

新規事業では、まず小さく作って確かめることが大切だと、私たちは考えています（小さく作って確かめる投資判断の進め方）。試作の段階で、すべてのセキュリティ確認を終える必要はありません。

一方で、実際のお客様の情報を扱う段階に進むときは、試作のまま公開しない、という線引きが要ります。AIが書いたコードも、AIを呼び出す基盤も、人が確認する工程を通してから公開する、という順番です（AI開発でも品質には人の確認が必要な理由）。

まとめ

今回の競技会で確認できたのは、次の点です。

Pwn2Own Ireland 2026で、OpenAI CodexやLiteLLMなどのAI関連ツールが、ZDIの公式結果の中で攻略された。
Codexは1件の引数インジェクション、LiteLLMは入力検証の不備とコードインジェクションと記録されている。
詳しい手順や修正状況は、今回確認できた範囲では公開されていない。

編集部の見方としては、AIを使うサービスでも、弱点の入口は従来のソフトウェアと重なる部分が大きく、構成図に部品を書き出して確認する価値があると考えています。

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に作る受託開発サービスです。開発基盤のLAFでは、人の役割を「何を作るかを決める」ことと「品質の最終判断」としています。AIを組み込んだ新規事業の進め方を考える際の参考として、サービスの紹介ページもご覧ください。

参考にした情報

← ブログ一覧へ