OpenAIのLinuxカーネル脆弱性948件の読み方|管理者が確かめるアカウントと更新

HOME > リナックスマスター.JP 公式ブログ > Linux情報・技術・セキュリティ > OpenAIのLinuxカーネル脆弱性948件の読み方|管理者が確かめるアカウントと更新
運営:リナックスマスター.JP(代表 宮崎智広)
「OpenAIがLinuxカーネルの穴を948件見つけたらしい。うちのサーバーは大丈夫なのか」

2026年11月4日、OpenAIが、AIを使った自動の調査でLinuxカーネルのローカル権限昇格(LPE)948件を検証し、修正パッチまで作ったと公表しました。

先に結論を書くと、948件は
「未修正の脆弱性が948個、そのまま放置されている」という数ではありません。
ただ、一般ユーザーからrootに届く脆弱性の修正が、
これから続けて出てくる見込みです。

管理者がやることは、次の2つです。
・ログインできるアカウントと、プログラムを動かしているユーザーを確認する
・カーネル更新を早く適用する段取りを決めておく

この記事では、20年以上Linuxサーバーの現場に携わってきた立場から、
公式発表の数字の読み方と、自分のサーバーで確認することを解説します。
想定環境はRHEL系とUbuntuです。攻撃の手口は扱いません。
数字は、2026年11月6日時点で公式発表と照合したものです。

この記事のポイント

・948は固有のLPEとして数えたパッチの数
・61・43・299はスキャン終了時点の修正状況
・古いカーネルの一般ユーザーはroot同等と考える
・ログインできる人と、カーネル更新の段取りを確認する


OpenAIのLinuxカーネル脆弱性948件の読み方|管理者が確かめるアカウントと更新
「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

OpenAIが公表した内容:948件の権限昇格はどう見つかったのか

OpenAIは、AIが自動で動かすパイプラインを作りました。
脆弱性の発見から悪用の検証、修正パッチの作成までを行います。
実行したのは2026年10月中旬です。
対象は、当時の最新のLinuxカーネル(masterブランチ)です。

使ったモデルは、公式の本文では「近く出すサイバー向けモデル」とされています。
OpenAIの別ページ(GPT-6 Cyberの紹介)では、
948件をこのモデルの成果として挙げています。

流れは5段階です。
・一般ユーザーから届くか、セキュリティに関係するかで絞り、脆弱性の候補を出す
・隔離した仮想マシンで実際に再現する
・情報漏えいや権限昇格に使えるかを試す
・修正パッチを作る
・人間の研究者が確認してから報告する

カーネルは4,000万行を超えます。
最初に、そのうち5,034か所・約280万行(全体の約7%)に絞っています。
件数は、次の表のとおりです。
段階 件数 公式の説明
コードを読んで出た候補 2,308件 12時間以内。重複を除いた数
仮想マシンで再現できたもの 1,724件 30時間以内。候補の約74.7%
悪用できそうなもの 情報漏えい313件・LPE 1,238件 悪用の道筋がないものを除いた候補
実際に動いたもの 情報漏えい291件・LPE 1,169件 LPEは一般ユーザーからrootを取れたもの
固有のLPE 948件 変種を分析して作ったパッチの数

検証用の仮想マシンは、
一般的なディストリビューションのデスクトップOSをそのまま使っています。
SMEP・SMAP・KASLR・HARDENED_USERCOPYといった標準の保護機能も有効です。
わざと守りを弱くした環境ではない、というのが公式の説明です。

費用はAPIの利用料で1,213,430ドル、
固有のLPE 1件あたり1,279ドルです。
2026年7月下旬には、同じ仕組みでGPT-5.6 Solを使いました。
そのときは166件(513,690ドル)でした。
3か月で、見つかる数が5倍を超えています。

少なくとも10種類の新しい悪用手法も見つかったとしています。
詳細は、安全上の理由で公開されていません。

同じような取り組みは、
4月にAnthropicのProject Glasswingの記事でも取り上げました。
今回の発表は、件数と費用を段階ごとに出している点が違います。

948は何の数か:読み違えやすい3つのポイント

1. 948は「固有のLPE」として数えたパッチの数

動いたエクスプロイトは1,169件でした。
同じ原因から派生したものを分析してまとめ、
作った修正パッチが948件です。
公式は「この数で固有のLPEの総数を決めている」と書いています。

また、パッチは「メンテナーの確認を受けるための候補」です。
948件のパッチが、そのままカーネルに取り込まれたわけではありません。

2. 対象は10月中旬の最新カーネル

調べたのは、当時の開発中の最新カーネルです。
いま動いているディストリビューションのカーネルは、
もっと前のバージョンを元にしています。

948件のそれぞれが、自分のカーネルにも含まれているかどうかは、
この発表だけでは判断できません。
発表には、CVE番号や修正コミットの一覧が無いからです。

個別の番号を追いかけるより、
ディストリビューションから届くカーネル更新を早く適用する方が確実だと考えます。

3. 「誰でも簡単に948件」という話ではない

今回の実行には、約121万ドルの費用と、
まだ一般に公開されていないモデルが使われています。

一方で、公式の考察部分(Reflections)には、次の見通しも書かれています。
「数年のうちに、脆弱性が公開されれば、
能力の低いモデルでもエクスプロイトを作れるようになる可能性がある」

管理者としては、修正の公開から攻撃に使われるまでの時間が、
短くなっていくと考えておく必要があります。

OpenAIのLinuxカーネル脆弱性948件の読み方|管理者が確かめるアカウントと更新 - 解説1

修正状況「61・43・299」はスキャン終了時点の数字

自動のスキャンと人の分析は、10日で終わりました。
公式によると、その時点の状況は次のとおりです。
・上流(本家のカーネル)で修正済み:61件
・修正パッチがステージング(取り込み待ち)に入っている:43件
・報告され、公開の場で議論されている:299件

公式の考察部分(Reflections)にも、
スキャン中の10日間の記述があります。
・100件を超えるLPEが「ほかの貢献者によって」修正またはステージング入りした
・さらに約300件が、公開の場で議論されていた

数字がほぼ同じなので、
上の3つと同じ状況を、別の箇所で書いたものと読めます。

また、OpenAIとは別に、
ほかの人も同じ脆弱性を見つけて修正していた、とも読めます。
同じ脆弱性を複数の人が見つけているなら、
修正のペースも早くなると見ておいた方がいいです。

948件全体については、公式は次のように説明しています。
・重大なものから、OpenAIが報告とパッチを送っている
・それ以外は、Patch the Planetのパートナーと一緒に順次送っている

Patch the Planetは、OpenAIのOSSメンテナー支援の取り組みです。

GPT-6 Cyberの紹介ページには、
重大なもの304件をパッチ候補つきでメンテナーに開示した、とあります。

61・43・299は、スキャン終了時点の数字です。
今の数字とは、違っている可能性が高いです。

AIのバグ報告でカーネル側の受け付け方が変わった経緯は、
Torvaldsの発言とカーネルML運用の変更についての記事にまとめています。

未更新なら一般ユーザーはroot同等という前提で、アカウントと実行ユーザーを確認する

OpenAIが管理者に向けた一文があります。

「当面のあいだ、最新のパッチを適用していないOSの、
低い権限のアカウントにアクセスできることは、
資金や人材の豊富な攻撃者にとっては、
root権限と機能的に同じとみなすべきだ」

今回の948件は、どれも
「ローカルの一般ユーザーがrootを取る」種類の脆弱性です。
外から直接rootを取られるわけではありません。
攻撃者はまず何らかの方法で、
一般ユーザーの権限でプログラムを動かす必要があります。

つまり、一般ユーザーの権限でプログラムを動かせる方法があれば、
そこからrootまで届く可能性があります。
よくあるのは、次の4つです。
侵入経路 よくある例 確認すること
SSHでログインできるユーザー 退職者・異動者のアカウントが残っている 今も使う人だけが残っているか
Webアプリの実行ユーザー アプリの脆弱性からコマンドを実行される アプリとミドルウェアが最新か
CIのランナーやバッチ 外部のコードやスクリプトを動かしている 誰のコードが、どのユーザーで動くか
コンテナを動かすホスト コンテナとホストはカーネルを共有している カーネルの更新がホスト側で済んでいるか

コンテナの中で動く処理も、ホストと同じカーネルを使っています。
そのため、カーネルの脆弱性は、コンテナの中からも悪用される可能性があります。

OpenAIは対策として、隔離による多層防御を挙げています。
FirecrackerやgVisorなどで、被害の範囲を限る方法です。

1. ログインシェルを持つアカウントを一覧にする

シェルがnologinやfalseになっていないアカウントを、一覧で表示します。

# ログインシェルを持つアカウント(ユーザー名・UID・シェル)を表示する getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}'

設定によっては、LDAPやActive Directoryから
参加しているユーザーが、getent passwd の一覧に出ません。
そのユーザーは、ディレクトリ側で確認してください。

表示されたアカウントは、「今も誰が使っているか」を1つずつ確認してみてください。
答えられないアカウントは、止める候補です。

2. SSHの公開鍵が置かれているアカウントを確認する

パスワードを変えても、公開鍵が残っていればログインできます。
鍵ファイルの場所は、sshdの設定で変えられます。
先に、sshdの設定を確認します。
OpenSSHの既定で読まれるのは、authorized_keysとauthorized_keys2です。

# sshdが読む鍵ファイルの場所を確認する sudo sshd -T | grep -i authorizedkeysfile # 各ユーザーとrootの鍵ファイル(authorized_keys・authorized_keys2)の有無と更新日時を確認する # (.sshは本人しか中を見られないので、*の展開もroot権限で行う) sudo sh -c 'ls -l /root/.ssh/authorized_keys* /home/*/.ssh/authorized_keys*'

鍵ファイルの場所が既定と違う場合は、そのパスで確認してください。
ホームディレクトリが/home以外のアカウントも同じです。

使っていないアカウントは、削除する前に、まずロックします。
sshdが UsePAM yes の場合(Ubuntuの既定)、
usermod -L だけでは公開鍵でのログインは止まりません。
usermodのマニュアルにも、アカウントごとロックするなら、
有効期限も1に設定するよう書かれています。

# パスワードを無効にし、アカウントの有効期限も切る sudo usermod -L -e 1 ユーザー名

ロックしても、すでにログインしているセッションや、
動いているプロセスは止まりません。
次の3の手順で、そのユーザーのプロセスが残っていないかも確認してください。

3. どのユーザーでプログラムが動いているかを確認する

サービスの実行ユーザーで動くプログラムも、
rootに届く経路になり得ます。

# 動いているプロセスの数をユーザーごとに数える ps -eo user= | sort | uniq -c | sort -rn

root以外のユーザーごとに、
「外から入ってきたデータを処理しているか」を確認してください。

Webアプリ、CI、外部のスクリプトを動かすユーザーがいるサーバーは、
カーネル更新の優先度も上げます。

カーネル更新を早く適用するための考え方

アカウントの確認は、攻撃に使える経路を減らす対策です。
経路をゼロにはできません。
もう1つの対策は、脆弱性そのものを早く修正することです。

OpenAIも、ソフトウェアを最新に保つよう呼びかけています。

1. 動いているカーネルと、届いている更新を確認する

カーネルの脆弱性は、パッケージを更新して修正する、と考える方は多いと思います。

これは正しいです。
でも、それだけでは足りない場面があります。
カーネルは、パッケージを更新しただけでは切り替わりません。
再起動するか、livepatchを適用するまでは、古いカーネルのままです。

# 動いているカーネルのバージョン uname -r # RHEL系:届いているカーネルの更新と、再起動が必要かどうか sudo dnf check-update kernel sudo dnf needs-restarting -r # Ubuntu:パッケージの一覧を更新してから、届いているカーネルの更新を確認する sudo apt update apt list --upgradable | grep linux-image # Ubuntu:このファイルがあれば再起動待ち ls /var/run/reboot-required

再起動待ちかどうかは、次の方法で判断します。
・RHEL系:dnf needs-restarting -r の表示
・Ubuntu:/var/run/reboot-required があるかどうか

ただし、update-notifier-common・unattended-upgrades の
どちらのパッケージも無い最小構成では、
/var/run/reboot-required が無くても再起動待ちのことがあります。
uname -r と、dpkg -l 'linux-image-*' の最新のバージョンも比較してください。
行頭が ii の行(インストール済み)だけを見てください。

needs-restarting が無い場合は、dnf-plugins-core をインストールしてください。
Ubuntuは apt update をしないと、
最新の更新が apt list に表示されないことがあります。
livepatchを使っている場合は、uname -r が古いままでも、
修正が適用済みのことがあります。

2. 再起動の日程を、先に決めておく

修正が届いてから再起動の日程を相談していると、
その間は古いカーネルのままです。
日程は「カーネルの更新が出たら、その週のうちに再起動する」のように、
先に決めておきます。

すぐに再起動できないサーバーでは、livepatchが選択肢になります。
適用した後の記録や、再起動に移る順番は、
livepatchを当てた後の運用設計の記事で詳しく解説しています。

3. 一般ユーザーがプログラムを動かせるサーバーから先に更新する

全台を同じ日に更新できないときは、
前の章で確認した経路が多いサーバーから更新します。
・複数の人がSSHでログインするサーバー
・Webアプリや外部のコードを動かすサーバー
・コンテナやCIのランナーを動かすホスト

管理者だけがログインし、外からのデータを処理しないサーバーは、
その後で構いません。

外部から攻撃できる脆弱性も含めた優先順位の付け方は、
CVE-2026-98432のCVSSの読み方の記事で整理しています。

OpenAIのLinuxカーネル脆弱性948件の読み方|管理者が確かめるアカウントと更新 - まとめ

まとめ:948件の数字より先に、自分のサーバーで確認すること

948という数字だけを見て、慌てる必要はありません。
確認することは、次の表のとおりです。
確認すること 理由 コマンド
ログインできるアカウント 一般ユーザーがrootに届く経路になり得る getent passwd | awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}'
鍵ファイルの場所 sshdの設定で場所を変えられる sudo sshd -T | grep -i authorizedkeysfile
SSHの公開鍵 パスワードを変えても鍵でログインできる sudo sh -c 'ls -l /root/.ssh/authorized_keys* /home/*/.ssh/authorized_keys*'
プログラムの実行ユーザー Webアプリ・CIも経路になる ps -eo user= | sort | uniq -c | sort -rn
動いているカーネル 再起動かlivepatchの適用まで修正は効かない uname -r
届いているカーネルの更新(RHEL系) 修正はディストリから届く sudo dnf check-update kernel
再起動待ちかどうか(RHEL系) 更新しても再起動するまで古いまま sudo dnf needs-restarting -r
届いているカーネルの更新(Ubuntu) apt update をしないと最新の更新が出ないことがある sudo apt update && apt list --upgradable | grep linux-image
再起動待ちかどうか(Ubuntu) ファイルがあれば再起動が必要 ls /var/run/reboot-required

前提は、
「最新のパッチを適用していないOSの一般ユーザーは、root同等とみなす」です。
そのうえで、アカウントと実行ユーザーを確認し、
カーネル更新を早く適用してください。

参考(一次情報)

・OpenAI「A thousand fewer paths to root」(2026年11月4日)
・OpenAI「GPT-6 Cyber」紹介ページ
・OpenAI「Patch the Planet」(2026年6月22日)

自分のサーバーに「誰がログインできるか」、すぐに答えられますか?

アカウントの棚卸し、カーネルの更新、再起動の段取り。どれも記事で読むだけでなく、実機で手を動かして初めて現場で使える知識になります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

※ 「独学の時間がもったいない」「プロから直接、サーバーの守り方を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

<PR>手元に置いて学びを深める1冊

Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本

まずは上の無料メルマガで学ぶのが第一歩です。加えて手元に置くなら、本書がサーバー防御の基本を学ぶ土台になります。2013年刊なので、コマンドは今のOSのマニュアルと照らして読んでください。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。