OpenAIは11月4日、脆弱性の発見から再現、悪用可能性の判定、修正パッチの作成までをエージェントで自動化した研究パイプラインの結果を、技術レポート「A thousand fewer paths to root」として公開した。10月中旬に最新のLinuxカーネルを対象に実行し、一般ユーザーがroot権限を得られる局所的権限昇格（LPE）の脆弱性948件について、動作するエクスプロイトと修正パッチ候補を用意した。API利用料は合計121万3,430ドルで、LPE1件あたり約1,279ドルになる。中核には未公開の次期サイバー向けモデルを使っている。
パイプラインは5段階で構成される。まず「Scout」エージェントがソースを読み、一般ユーザーから到達でき、かつセキュリティ上重要な5,034の監査対象（約280万行、カーネル全体の約7%）を選び出した。次に「Analyst」エージェントが各対象を解析して12時間で2,308件の脆弱性候補を挙げ、トリアージ用のエージェントがKASAN（カーネルのメモリ破壊検出機能）を有効にした隔離VMで実証コードを書いて再現を試み、30時間で1,724件（約75%）を再現した。モデルの解析そのものが誤っていた候補は3.1%にとどまった。
再現できた脆弱性については、SMEP・SMAP・KASLRなど一般的なディストリビューションと同じ保護機能を有効にした環境でエクスプロイト作成を試み、情報漏えいの実証コード291件と、root権限を取得できるLPEエクスプロイト1,169件を得た。同じ原因に由来するものをまとめて修正パッチを作ると948件になり、これが固有のLPE数として数えられている。最後に人間の研究者がエクスプロイト・パッチ・深刻度を確認してからメンテナーに報告する流れで、重大なものから数百件の報告とパッチをすでに送付した。残りは6月に始めたオープンソース支援の取り組み「Patch the Planet」のパートナーと順次送る。
7月のGPT-5.6 Solでは166件、3か月で5倍超に
同じパイプラインは7月下旬にもGPT-5.6 Solで実行されており、見つかった固有のLPEは166件、費用は51万3,690ドルだった。10月の実行では、その間に3か月分のカーネル修正が進んでいたにもかかわらず948件を見つけている。費用は約2.4倍、発見数は約5.7倍で、1件あたりのコストは半分以下に下がった。6月にGPT-5.5 Cyberで報告したLPEエクスプロイトは24件だったので、約5か月で約40倍に増えたことになる。
レポートは、モデルが強くなるほど周辺の補助を簡素化できるという観察も示している。GPT-5.5 Cyberでは、既知のカーネル攻略手法103種類を整理して環境に置き、使うよう指示すると、63件の候補での成功率が76.2%から88.9%に上がった。一方GPT-5.6 Cyberは手法を自力で選んで適用でき、この補助を外した構成がGPT-5.5 Cyberの補助あり構成を上回った。補助を戻しても改善は1.5ポイントにとどまり、保守コストに見合わないとして外している。また、サンプル調査した166件のエクスプロイトからは、外部のカーネル攻略専門家も知らなかった新しい手法が10種類見つかった。詳細は安全上の理由で公開していない。
バグ報奨金との比較と、自動化で見つかった落とし穴
OpenAIは費用対効果を報奨金額で換算している。Pwn2OwnとTyphoonPWNは過去にLinuxカーネルのLPEにそれぞれ2万ドルと7万ドルを提示しており、948件に当てはめると1,890万〜6,630万ドルで、実行費用の16〜55倍になる。攻撃面を絞ったGoogleのkernelCTF環境でも、約3万3,000ドルの費用でLPE21件を得た。kernelCTFが2026年に受理した0-dayのLPEは執筆時点で26件で、その数に迫る件数を1回の実行で得た計算になる。
自動化の落とし穴も報告されている。初期の実行で成功と判定された200件のLPEのうち20件は、割り当てられた脆弱性ではなく別の未知の脆弱性を使ってrootを取っていた。そのため、結果だけでなく攻略の経路も確かめる独立したチェックを追加した。検証用の仮想化基盤であるQEMUの脆弱性もエージェントが見つけて悪用しており、上流では修正済みだったが実験に使ったリリース版には残っていた。
カーネルのメンテナー側の対応も速く、10日間のスキャン期間中に61件のLPEが上流で修正され、43件が修正準備中、299件が公開の場で議論されていた。OpenAIはこれを踏まえ、最新パッチを当てていないOSで一般ユーザー権限を取られることは、資金力のある攻撃者にとってはroot権限を取られるのとほぼ同じとみなすべきだとし、FirecrackerやgVisorのような隔離技術による多層防御を勧めている。修正が数十件単位で日々上流に入っている状況では、サーバー運用側にとってカーネル更新の間隔を詰めることが最も直接的な対策になる。
