OpenAIは2026年11月4日、試作段階のAIシステムを使い、Linuxカーネルで948件のローカル権限昇格の脆弱性を実証し、それぞれの修正案を作成したと発表した。10月中旬時点の開発コードを対象とした研究で、脆弱性の探索から攻撃による検証、修正案の生成までを一連の工程として実施した。
ローカル権限昇格とは、システム上でプログラムを実行できる低権限の利用者が、管理者であるrootの権限を不正に取得する攻撃を指す。外部から直接侵入できるリモート攻撃とは異なり、原則として対象システム上でコードを実行できることが前提となる。また、攻撃を実証できたことと、その脆弱性が修正され、利用者の環境に対策が届いたことは別の話だ。今回の成果を評価するには、948件という数字の内訳に加え、検証に要した時間や修正案の採用状況を区別して見る必要がある。
948件の脆弱性はどのように発見・実証されたのか
今回の調査では、低権限の利用者から到達できるコードに対象を絞り、5,034の監査対象に含まれる約280万行を分析した。これはLinuxカーネル全体の約7%に相当し、カーネル全体を網羅的に調査した結果ではない。まず、脆弱性の探索を担当するAIエージェント「Analyst」が12時間で重複を除いた2,308件の候補を抽出した。
続いて、メモリ関連の不具合を検出するKASAN（Kernel Address Sanitizer）を組み込んだ隔離仮想マシン（VM）を使い、候補となった問題を実際に再現できるか検証した。OpenAIも、候補として報告された問題と、実際に検証された脆弱性は同じではないと強調している。つまり、AIが疑わしいコードを見つけただけで、それをすべて実在する脆弱性として数えたわけではない。
調査結果を工程別に整理すると、次のようになる。ここで重要なのは、各工程で数えている対象が異なることだ。また、30時間という数字は動的検証に要した時間であり、人間による分析を含めた調査全体の所要期間とは異なる。
| 工程 | 件数 | 所要時間・検証条件 | 内容 |
|---|---|---|---|
| 脆弱性の探索 | 候補2,308件 | 12時間 | 重複を除いた脆弱性の候補 |
| 動的検証 | 再現1,724件 | 30時間以内、KASANを有効化した隔離VM | 実際の実行によって問題を確認 |
| 攻撃の実証 | 攻撃コード1,169本 | 標準的なLinuxディストリビューションの防御機構を有効にしたVM | root権限の取得に成功した攻撃コード |
| 変種の分析・整理 | 権限昇格の脆弱性948件 | 異なる948件の修正案を基準に整理 | 同じ問題の変種を分析・整理した後の件数 |
この結果はOpenAIが10月中旬に実施した調査に基づくもので、自律的なスキャンと人間による分析を終えるまでには10日間を要した。
最初に抽出した2,308件の候補のうち、実際に再現できたのは1,724件で、割合にすると約74.7%だった。ただし、再現できなかった候補にも、実行権限の条件や競合状態、検証時間の制約などが影響するため、残りをすべて誤検知とみなすことはできない。さらに悪用可能性を検証した結果、root権限の取得に成功する攻撃コード1,169本が作成され、同じ問題の変種を整理した最終的な件数が948件となった。
この過程では、権限昇格とは別に291件の情報漏えいも実証している。単に不具合を発見するだけでなく、実際にどのような攻撃につながるかを検証したことになる。一般的なLinuxディストリビューションの防御機構を有効にした環境で攻撃を成功させた点は注目に値するが、すべてのLinux環境が同様に影響を受けることを意味するわけではない。個々のディストリビューションへの影響や修正の配布状況も、今回の件数だけでは判断できない。
OpenAIは2026年6月にもGPT-5.5 Cyberを使って24件の脆弱性を実証しており、7月下旬のGPT-5.6 Solによる調査では166件に増えていた。今回は探索と動的検証に加えて修正案の生成まで対象を広げ、10月の調査では今後公開予定のサイバーセキュリティ向けモデルを中核に使用している。ただし、各調査で対象としたカーネルの開発コードが異なるため、発見件数の増加をそのままAIモデルの性能向上率とみなすことはできない。今回の調査全体にかかったAPI費用は121万3,430ドルであり、人件費や設備費などを含む総費用ではない。
root権限を取得しても、指定された脆弱性を悪用したとは限らない
今回の研究では、AIによる攻撃の検証方法にも課題が見つかった。初期の実行では、攻撃に成功したと判定された200件のうち20件が、指定された脆弱性ではなく、別のゼロデイ脆弱性を利用してroot権限を取得していた。AIに与えられた目標がroot権限の取得だけであれば、調査対象とは別の脆弱性を使っても成功条件を満たしてしまう。結果として攻撃そのものは成功していても、指定した脆弱性の悪用可能性を証明したことにはならなかった。
この問題は、修正の有効性を検証する際にも影響する。指定した脆弱性を修正しても、検証用の攻撃コードが別の脆弱性を悪用していれば、その攻撃コードの成否だけでは修正が正しいか判断できないためだ。OpenAIはこの問題を受けて検証条件を厳格化し、指定された脆弱性が実際に利用されているかを独立して確認する工程を追加した。なお、200件中20件という数字は初期段階で確認された問題であり、最終的な948件の誤り率を示すものではない。
修正案の品質にも課題があった。初期の修正案には変更範囲が大きすぎるものや、性能面の懸念があるもの、Linuxカーネルの開発規約に沿っていないものが含まれていた。また、問題の直接的な原因を修正できても、同じ脆弱性の別の変種を見落とす例があったという。目の前の攻撃を防げたとしても、類似した経路に問題が残っていれば、根本的な解決にはならない。
OpenAIは、追加の指示と修正の反復によって、こうした問題を改善したと説明している。ただし、修正案の品質が改善したことと、そのすべてがLinuxカーネルの保守担当者に採用されたことは同義ではない。同社はAIが作成した攻撃コードと修正案を人間が確認し、深刻度も評価したうえで保守担当者に報告する手順を採用している。AIによって脆弱性の発見と攻撃の実証を高速化できても、原因の特定や修正内容の妥当性を確認する工程は省略できない。
948件の修正案は、実際のLinux環境にどこまで届いたのか
10日間の自律スキャンと人間による分析が完了する頃には、OpenAIによると61件が開発元のコードで修正済みとなり、43件は取り込みに向けたパッチの準備段階、299件は公開の報告や議論が進められている段階にあった。ただし、これは研究中の特定時点における状況であり、11月5日時点の最新の修正状況を示したものではない。また、この内訳だけを使って948件のうち現在何件が未修正なのかを計算することもできない。
OpenAIは深刻な問題を優先して数百件の脆弱性報告と修正案を提出し、残りについても協力先と調整しながら段階的に報告を進めていると説明する。AIによって脆弱性の発見件数が急増すれば、報告を受け取る保守担当者の負担も大きくなる。発見した問題の原因を確かめ、最新のコードでも再現するか検証し、適切な修正を審査する作業を同時に進めなければならない。防御面での成果を測るには、AIが生成した修正案の数だけでなく、実際に採用・配布され、対象環境で有効性が確認された修正の数も重要になる。
The Hacker Newsの報道も、今回の研究をAIが攻撃側と防御側の双方にもたらす変化として取り上げ、脆弱性への対策を組織が検証・適用する体制の重要性に言及している。また、英国国家サイバーセキュリティセンター（NCSC）が11月3日に公表した報告書では、AIによるサイバー攻撃や防御の変化について、2028年を対象とする三つのシナリオを示している。
ただし、NCSCはこれらのシナリオを「予測ではない」と明確に位置づけている。AIによってパッチの作成が加速する一方、組織側にも修正を試験・適用する体制の見直しが求められるという指摘は、基本シナリオに含まれる将来の想定だ。すでに実測された変化を示すものでも、OpenAIが報告した948件の脆弱性を独立に検証した結果でもない。
今回の脆弱性の件数やAPI費用はOpenAI自身の報告に基づいており、第三者による独立した追試や、すべての修正案の監査完了が確認されたわけではない。それでも、AIを使って脆弱性の発見から攻撃の実証、修正案の生成までを大規模に進められることを示した点は重要な成果といえる。今後の焦点は、AIがどれだけ多くの脆弱性を発見できるかに加え、その成果をLinuxカーネルの正式な修正として取り込み、利用者の環境へ安全かつ迅速に届けられるかに移っていくだろう。
