OpenAIのAIが、Linuxでroot権限を取れる欠陥948件を攻撃コードで実証した実験｜費用の内訳と、先に更新するサーバーの選び方
OpenAIがAIで実証した、Linuxで一般ユーザーがrootになれる欠陥948件
OpenAIは2026年11月4日、Linuxカーネルの欠陥をAIで探して修正案まで作る試作の仕組みについて、研究報告を公開しました。10月中旬の1回の実行で、動く攻撃コードを1,169件作り、同じ欠陥を使うものをまとめると、一般ユーザーが管理者（root）の権限を取れる欠陥は948件だったとしています。API費用は合計1,213,430ドル（約121万ドル）です。
Linuxカーネルは、OSの中心でメモリやファイル、ネットワークを管理するプログラムです。クラウドのサーバーなどに使われています。今回の欠陥は「ローカル権限昇格」と呼ばれる種類で、マシンに一般ユーザーとして入った人が、すべての操作ができるrootになれるものです。
この記事では、OpenAIの報告をもとに、948という数の意味、費用の内訳、修正の進み具合を整理します。後半はLinuxを管理している人に向けて、どのマシンを先に更新するかの決め方と、カーネルの版や再起動の要否を確かめるコマンドをまとめます。
記事の要点
他人のコードを動かすLinuxから順に、カーネルを更新して再起動する
筆者計算と記したもの以外の数字は、OpenAIの2026年11月4日の報告によるものです。
攻撃コードで実証した欠陥
948件
一般ユーザーがrootになれる欠陥の数です。動いた攻撃コード1,169件から、同じ欠陥を使うものをまとめました。
欠陥1件あたりのAPI費用
1,279ドル
OpenAIの公表値です。同じ仕組みを7月に動かした回の約3,095ドルから約6割下がりました（筆者計算）。
カーネルの管理者への報告
数百件を送付済み
OpenAIは深刻なものから送りました。残りはOpenAIの支援事業の提携先と順に送ります。
OpenAIの助言
一般ユーザーもrootと同じ扱いに
未更新のOSでは、一般ユーザーのアカウントを奪われるとrootまで取られると考えるよう勧めています。相手は資金のある攻撃者です。
948件は、一般ユーザーとしてLinuxに入った人がrootになるための欠陥
948件の欠陥で攻撃するには、対象のマシンで一般ユーザーとしてプログラムを動かせることが前提です。インターネットから直接サーバーを乗っ取る欠陥を数えたものとは、前提が異なります。たとえば、盗んだパスワードでログインした人や、Webアプリの弱点から一般ユーザーの権限でコマンドを実行した人が、その次の段階で使う欠陥です。
実験には、保護機能を弱めていない標準構成のデスクトップOSを使いました。SMEP、SMAP、KASLR、HARDENED_USERCOPYという、カーネルへの攻撃を難しくする機能を有効にしています。OpenAIは「広く使われているLinuxディストリビューション」とだけ書いており、製品名は挙げていません。AIモデルも「今後提供予定のサイバーモデル」と呼ぶだけで、名前を明かしていません。コードを調べた対象はカーネルの開発版（masterブランチ）で、攻撃コードを試した環境はデスクトップ向けの標準構成です。OpenAIの助言はデスクトップに限らず、OS全般に向けたものです。
948という数には数え方の決まりがあります。動く攻撃コードそのものは1,169件できました。同じ修正案で直せる攻撃コードを1件に数えると948件になったため、OpenAIはこの数を、重複を除いたローカル権限昇格の件数としています。
AIは候補を実際に動かして、欠陥948件を確かめた
AIは欠陥の候補を挙げたあと、隔離した仮想マシンの中で実際に動かして確かめました。工程を、筆者が次の5段階に整理しました。
Linuxカーネルを調べた5段階と、各段階の件数
1. 調べる範囲を決める：監査対象 5,034件
一般ユーザーの操作で届くコードを選びました。合計約280万行で、カーネル全体の約7%です。
2. コードを読んで候補を挙げる：候補 2,308件
重複を除いた数です。この工程にかけた時間は12時間以内です。
3. 隔離した仮想マシンで再現する：再現 1,724件
候補の約74.7%を再現しました。この工程にかけた時間は30時間以内です。AIの分析そのものが誤っていた候補は3.1%です。
4. 攻撃に使えそうな候補を選び、攻撃コードを作って試す：動いたコード 1,169件、重複を除くと948件
rootを狙える候補1,238件を選んで試しました。情報を盗み出せることを示す実証コードも291件できています。
5. 修正案を作り、人が確かめて報告する
セキュリティの研究者が攻撃コード、修正案、深刻度の評価案を確かめてから、カーネルの管理者へ送ります。
再現できなかった約4分の1の候補について、OpenAIはその大半の理由を挙げています。より高い権限が必要だった、タイミングに左右される欠陥で再現が難しかった、制限時間内に検証が終わらなかった、といったものです。
API費用約121万ドルの64%は、攻撃コードの作成に使われた
OpenAIは各工程のAPI費用を公開しています。報告の数字を足し合わせると、総額との差は2ドルでした。割合は筆者が計算したものです。
工程別のAPI費用（総額1,213,430ドル）
攻撃コードの作成：775,929ドル（63.9%）
コードを読んで候補を挙げる：316,549ドル（26.1%）
仮想マシンでの再現：73,330ドル（6.0%）
攻撃に使えそうかの選別：44,194ドル（3.6%）
調べる範囲の決定：3,426ドル（0.3%）
出典：OpenAI「root 権限への経路を 1,000 件削減」。報告は修正案の生成の費用を別に示していません。5項目の合計は総額とほぼ一致します。別の項目に含まれるか、総額の外にあるかは報告から分かりません。
失敗した試行は、1件あたりの費用が成功の約11倍でした（筆者計算）。図の775,929ドルのうち、root権限を狙う攻撃コードの作成には691,000ドルを使い、残りは情報を盗み出す実証コードの費用です。この691,000ドルの内訳は、成功した1,169件が平均約360ドル、失敗した69件が平均3,922ドルで、失敗は件数で約6%ですが費用では約39%を占めます（割合は筆者計算）。OpenAIは、1時間進まなければ打ち切るといった条件を置けば費用を大きく減らせたと見ています。仕組みを最適化すれば各工程の費用も下げられるとして、公表した費用は上限に近い値と捉えるよう書いています。
7月の実行と比べ、10月の実行で実証した欠陥は5.7倍になった
OpenAIはこの仕組みを開発していた7月下旬にもGPT-5.6 Solで実行しており、その数字も公開しています。どちらも実行時点で最新の開発版（masterブランチ）を調べました。
2026年7月下旬（GPT-5.6 Sol）
166件
総額513,690ドル
1件あたり約3,095ドル（筆者計算）
2026年10月中旬（今後提供予定のモデル）
948件
総額1,213,430ドル
1件あたり1,279ドル
7月から約3か月のあいだに修正が進んだカーネルでも、10月の実行は7月の5.7倍（948÷166、筆者計算）の欠陥を見つけました。OpenAIの表現は「5倍を超える」です。OpenAIはこの結果から、新しい世代のモデルが出るたびに同じコードを調べ直すよう勧めています。
欠陥1件ずつに報奨金が出ると仮定すると、総額はAPI費用の約16〜55倍になる
OpenAIは費用を、欠陥の報告に支払われる報奨金とも比べています。Pwn2OwnとTyphoonPWNというコンテストが過去にLinuxカーネルの権限昇格へ設定した報奨金は、それぞれ2万ドルと7万ドルです。これを948件へ当てはめると約1,900万〜6,600万ドルで、API費用の約16〜55倍になります。すべてに報奨金が出たと仮定した計算で、実際に受け取った額とは別のものです。
Googleの報奨金制度kernelCTFの環境に一部調整を加えた実行でも、112時間、約32,936ドルで攻撃コードが21件できました。調整の一つとして、使ったカーネルと互換性がなかった保護機能SLAB_VIRTUALを設定から外しています。同制度は1件あたり71,337ドルと定めており、20回の実行で70%以上成功することなどを条件にしています。OpenAIは、21件すべてが受理されれば約150万ドルになると計算しています。同制度の報奨の対象環境ではSLAB_VIRTUALが有効なので、これは受理された場合の仮定の金額です。
OpenAIの計算では、公表された報奨金額を基準にすると、この仕組みの費用より報奨金の総額のほうが大きくなります。OpenAIはこの結果を踏まえて、攻撃者にとって割に合わなくなるよう、防御側が先に自分のソフトウェアを調べて直すことを勧めています。
948件の修正案のうち、人が確かめて送ったのは数百件
AIは948件の欠陥それぞれに修正案を作りました。OpenAIがカーネルの管理者へ送ったのは、深刻なものから数百件です。残りは、OpenAIのオープンソース支援事業Patch the Planetの提携先と順に送る計画です。送った修正案のうちLinuxへ取り込まれた件数は、報告に書かれていません。
スキャンの開始から10日後に進んでいた修正と議論
61件
カーネル本体へ修正が取り込まれていた
43件
修正を取り込む準備が進んでいた
299件
公開の場で報告・議論されていた
OpenAIの報告による数字です。61件と43件は他の貢献者によるパッチで、299件は公開の場で報告や議論が進んでいたものです。OpenAIは、重複した報告を避けるため、検出結果を最新のコードで確かめ直す必要があると書いています。
カーネルの開発側は、AIで見つかる報告が増えることにすでに対応を始めています。Linuxカーネルの開発を率いるLinus Torvalds氏は2026年5月のLinux 7.1-rc4の告知で、同じAIツールで同じ欠陥を見つけた人の報告が重なり、非公開のセキュリティ窓口の処理が追いつかなくなっていると述べました。今のカーネルの報告ルールは、AIで見つけた欠陥を公開の情報として扱い、テスト済みの修正案を添えることを求めています。欠陥を再現するコードは公開の場に載せず、管理者に求められたときに渡します。
OpenAIが人の確認を残している理由も、報告に具体例があります。
AIが指定外の欠陥でrootを取り、成功と報告した
初期の実行で成功と報告された200件のうち20件は、指定とは別の未知の欠陥を使っていました。その後、指定の欠陥を使ったかを確かめる別のチェックを足しています。
AIの修正案に品質の問題があった
当初の修正案には、ときに、不要なコードの追加、性能の低下を招くおそれ、コーディング規約からの逸脱、同種の欠陥の見落としがありました。指示の追加と作り直しで改善したとしています。
カーネルの外にあるQEMUの欠陥も攻撃した
kernelCTF向けの実行では、仮想マシンを動かすQEMUの欠陥まで見つけて攻撃コードにしました。最新のQEMUでは直っていて、実験に使った版では残っていたものです。OpenAIの研究者が攻撃コードを手作業で分析して気づきました。
先に更新するのは、他人のコードを一般ユーザーの権限で動かすLinux
OpenAIは、未更新のOSでは一般ユーザーのアカウントでも、資金のある攻撃者にとって実質的にrootと同じだと考えるべきだと書いています。そこで、自分が管理するLinuxのどれを先に更新するかを、一般ユーザーの権限で動くコードを誰が持ち込めるかで分けました。この分け方は筆者の判断で、OpenAIの報告にあるものとは別です。
優先度 高：今週中に更新して再起動する
複数の人がログインする開発サーバーや共有サーバー、外部から届くコードを動かすCIのランナー（テストなどを自動で動かすサーバー）、利用者のコードを実行するサービス
優先度 中：定期更新の間隔を短くする
インターネットに公開したWebサーバーです。WordPressのプラグインの弱点などから一般ユーザーの権限でコマンドを実行された場合、次の段階でカーネルの欠陥を使われるおそれがあります。他人のコードが動くまでに、Webアプリの弱点を突く段階が1つ増える分、優先度を1つ下げました。プラグインの更新が滞っているサーバーは高に上げます。
優先度 標準：いつもの周期で更新する
自分だけが使う手元のLinuxです。npmやpipで入れるパッケージ、配布元以外のスクリプトも他人のコードです。これらを日常的に動かすなら、優先度を1つ上げます。
OpenAIは残りの修正案をこれから順に送る段階です。948件の修正がディストリビューション（UbuntuやRHELなどの配布元）のカーネルへ届くまでには、時間がかかるとみておきます。いま更新して防げるのは、配布元がすでに修正を配った欠陥です。調べた対象は開発版なので、自分のカーネルに何件当てはまるかは報告から分かりません。948件の一覧も載っていないので、1件ずつ照合する方法はありません。対象のマシンを今のうちに一覧にし、配布元の修正が届くたびに更新して再起動できる手順を整えます。
更新は配布元が配るカーネルで行います。kernel.orgの番号（2026年11月6日時点で最新の安定版は7.3.1、長期サポート版は6.18.60、6.12.115など）は開発元のもので、配布元のカーネルの番号とは別の体系です。配布元が出した修正を適用済みかどうかは、配布元のセキュリティ情報で確かめます。
カーネルを更新したら、再起動して新しい版が動いていることを確かめる
新しいカーネルをインストールしても、古いカーネルは再起動するまで動き続けます。次のコマンドで、動いている版と再起動の要否を確かめられます。uname -r の結果は、配布元の最新のカーネルの版と比べます。Ubuntu 24.04とRocky Linux 9のコンテナでコマンドの動きを確かめました（カーネルの入れ替えそのものと、Livepatchのコマンドは含みません）。
# 動いているカーネルの版を表示する
uname -r
# Ubuntu：このファイルがあれば再起動待ち
ls /var/run/reboot-required
# RHEL（企業向けのLinux）・Rocky Linux系：終了コード1なら再起動が必要、0なら不要（要 yum-utils）
needs-restarting -r; echo $?Debianでは、unattended-upgrades が入っていないと、カーネルを更新してもこのファイルが作られないことがあります（Debian 12のコンテナで、このファイルを作る処理がこのパッケージに含まれることを確かめました）。ファイルがないことだけで再起動は不要と決めず、uname -r の結果を ls -v /boot/vmlinuz-* の最後の行と比べます。Debian 12の uname -r は 6.1.0-54-arm64 のような形式で、パッケージの版（6.1.190-1）と表記が異なるためです。
UbuntuのLivepatchは、再起動せずに修正を当てる仕組みです。次の起動で入るカーネルの修正をLivepatchで適用済みと判定すると、/var/run/reboot-required を消します。Livepatchを使っているサーバーでは、ファイルの有無に加えて、canonical-livepatch status で適用状況を確かめます。
コンテナの中の一般ユーザーも、サーバー本体と同じカーネルを使う
他人のコードをコンテナで動かしている環境では、更新の計画を立てる前に、コンテナとサーバー本体が同じカーネルを使っていることを確かめます。手元のDocker Desktop（Engine 29.5.3）で、異なるOSのイメージから版番号を表示しました。
$ docker run --rm alpine:3 uname -r
6.12.76-linuxkit
$ docker run --rm ubuntu:24.04 uname -r
6.12.76-linuxkit
$ docker run --rm debian:12 uname -r
6.12.76-linuxkit
$ docker run --rm --user 1000 ubuntu:24.04 sh -c 'id -u; uname -r'
1000
6.12.76-linuxkitどのイメージでも、一般ユーザー（UID 1000）で動かしても、同じカーネルの版が返りました。Dockerは権限を減らして動かすことで、コンテナの中からできる操作を絞っています。カーネルはコンテナの外と共通なので、操作を絞ったあとも、カーネルの欠陥を突く経路が残る場合があります。カーネルの更新はコンテナイメージの更新と別の作業で、カーネルが動いている側（サーバー本体やDocker Desktopの仮想マシン）を更新します。
他人のコードを動かす環境をさらに分けるなら、OpenAIはgVisorとFirecrackerを例に挙げています。gVisorはアプリのシステムコール（カーネルへの処理の依頼）を独自のカーネルで受けて、ホストのカーネルへ直接渡さない仕組みです。Firecrackerは利用者ごとに小さな仮想マシンを立ち上げる仕組みで、複数の利用者を同じサーバーに載せるサービス向けに作られています。OpenAIはgVisorやDockerの欠陥も開示・修正してきたと述べており、分離の仕組み自体も更新の対象です。
948件はOpenAIの自社発表で、外部の裏づけはこれから増える
948件、費用、再現率など実験の数字は、OpenAIが自社の研究として公表したものです。OpenAIは、抽出した166件の攻撃コードでAIが新しい攻撃手法を10種類使い、外部のカーネル攻撃の専門家に共有したところ未知の手法だったとも説明しています。攻撃コードは公開されておらず、10種類の手法も安全上の理由で詳細が伏せられています。
続報を追うなら、カーネルのメーリングリストと安定版に入る修正を見ます。OpenAIが報告した修正を確かめられれば、数字の一部を外部の記録と突き合わせられます。OpenAIがkernelCTFへ提出して受理された場合は、その結果も手がかりになります。
今週やる3つのこと
1. 他人がログインできるLinuxと、他人のコードを動かすLinuxを一覧にする
2. その一覧のマシンでカーネルの版（uname -r）と再起動の要否を確かめ、ディストリビューションが修正を出していれば、更新して再起動する
3. 他人のコードをコンテナだけで分けている環境は、カーネルが動いている側の更新手順と担当者を決める