「サーバーに修正を入れました」は確認が要る｜2026年11月のLinuxカーネル脆弱性で、実際には入っていなかった話

修正の通知を受けたら、再起動の前に、いま動いているカーネルのバージョン番号を確認してください。

2026年11月に何が起きたのか

Linuxカーネルの、IPv4のTCP接続を受け付ける処理に脆弱性が見つかりました（CVE-2026-98432）。ログインしていない第三者が、外から接続を受け付けているポートへ「IPオプション」という付加情報を付けた接続要求を送ることで、サーバー上でプログラムを実行される可能性があります。

Webサイトの80番や443番に限らず、SSHなど、外から接続を受け付けているポートが1つでもあれば対象です。インターネットに公開しているLinuxサーバーは、基本的に対象と考えてください。

深刻度はCVSS v3.1で9.8（Critical）、Ubuntuの優先度もCriticalです（出典：NVD・Ubuntu Security、2026年11月7日確認）。CVEとしての公開は2026年10月15日です。Ubuntuは各バージョン向けに修正済みのカーネルを準備している途中で、11月7日時点の表記は「対応中」です。

Ubuntu以外のLinuxも対象

この脆弱性は、Linuxカーネルそのものにあります。Ubuntuに限らず、Red Hat Enterprise Linux・Debian・Amazon Linuxなど、Linuxで動くサーバーは基本的に対象です。ただし、修正済みのバージョンと配布の時期は、配布元ごとに違います。

出典は、Ubuntu Security・Red Hat Customer Portal・Debian Security Tracker・Amazon Linux Security Centerの各ページです（2026年11月7日確認）。深刻度の評価も配布元で分かれていて、Amazon Linuxは攻撃の条件が厳しいとしてCVSS v3.1で8.1としています。

この記事では、FUNBREWのサーバーで使っているUbuntuを例に説明します。ほかのLinuxでは、各配布元のページで修正済みのバージョンを確認してください。

「修正を入れました」という通知と、実際の状態

日本時間の11月7日未明、FUNBREWが使っているサーバー管理サービスから、次の内容の通知が届きました。

• 脆弱性を修正したカーネルを、対象のすべてのサーバーに入れた
• カーネルの更新は再起動して初めて効くので、都合のよい時間に再起動してほしい

同じ日の朝に届いた2通目では、「環境によっては自動で入れた修正が効いたか確認できないので、各自で確認してほしい」と補足されました。

FUNBREWが管理するサーバーを1台ずつ調べたところ、修正済みのカーネルが入ったサーバーはありませんでした。この状態で再起動しても、古いカーネルのまま起動するだけで、脆弱性は残ります。実際、通知のあとに別の理由で再起動したサーバーも、修正前のカーネルのまま起動していました。

なぜ自動で入らなかったのか

Ubuntuは更新を、目的別に分けた配布元から配っています。

Ubuntuの自動更新（unattended-upgrades）は、標準の設定ではsecurityの更新だけを入れます。今回の修正済みカーネルは、11月7日時点でupdatesには出ていましたが、securityにはまだ載っていませんでした。そのため、標準の設定のサーバーでは、自動では入りません。

「再起動が必要」の表示は、修正済みの印ではない

「再起動が必要」という表示は、主に次の2か所で目にします。

• サーバーにログインしたとき：Ubuntuは、再起動しないと効かない更新が入ると、/var/run/reboot-required というファイルを作ります。このファイルがあると、ログインしたときに「*** System restart required ***」と表示されます
• サーバー管理サービスの画面：再起動が必要なサーバーに印を付けるサービスもあります。何をもとに印を付けているかは、サービスによって違います

Ubuntuのこのファイルは、カーネルに限らず、Cの標準ライブラリのような基本的なソフトウェアの更新でも作られます。また、再起動するまで消えないので、しばらく再起動していないサーバーでは、何か月も前の更新で作られたファイルが残っていることもあります。

そのため、表示があっても、今回の修正済みカーネルが入っているとは限りません。どの更新で再起動が必要になっているかは、/var/run/reboot-required.pkgs の中身で確認できます。修正が効いているかどうかは、どちらの表示にも頼らず、次の節の方法でバージョン番号を確認してください。

自分のサーバーで確認する方法

サーバーにログインして、次のコマンドで、いま動いているカーネルのバージョンを表示します。

uname -r

Ubuntuは、次のバージョンで今回の脆弱性を修正するとしています（出典：Ubuntu SecurityのCVE-2026-98432のページ、2026年11月7日確認）。表示された番号がこれ以上なら、修正の入ったカーネルで動いています。

20.04 LTSと18.04 LTSは、11月7日時点で修正のバージョン番号がまだ示されていません。表にない種類のカーネルは、Ubuntu SecurityのCVE-2026-98432のページで確認できます。

表示された番号が表より小さいときは、次のコマンドで、サーバーに入っているカーネルの一覧を表示します。一覧の中に表のバージョン以上のものがあれば、修正済みのカーネルは入っていて、再起動すれば効きます。無ければ、先にカーネルを更新する必要があります。

ls /boot/vmlinuz-*

すぐに更新できないときの応急処置

Ubuntuは、修正済みのカーネルに更新するまでの応急処置として、IPオプションの付いたTCPの通信を受け付けないファイアウォールの設定を公開しています。通常のWebサイトの通信はIPオプションを使わないので、多くの場合は影響なく設定できます。

ただし、Ubuntu自身が「危険を減らすが、完全には防げない」としています。また、サーバーで使っているファイアウォールの仕組みによって設定の仕方が変わります。あくまで更新までのつなぎとして、サーバーの管理者と相談して入れてください。

FUNBREWではどう対応したか

FUNBREWでは、次の順番で対応しました。

1. サーバーごとに、使っているカーネルの種類だけを更新した（ほかのソフトウェアはまとめて更新しない）
2. 影響の小さいサーバー1台を先に再起動し、修正済みのカーネルで起動することと、サービスがすべて動くことを確認した
3. 社内向けのサーバーは、作業中の処理が無いことを確認してから、昼のうちに1台ずつ再起動した
4. お客様がお使いのサーバーは、もともと決めている夜間の再起動の時間帯に再起動する
5. お客様がお持ちのサーバーは、事前にご連絡してから作業する

AWS向けの7.0系のように、11月7日時点で修正済みのカーネルの配布が始まっていない種類もあります。その場合は、配布を待つあいだに応急処置を入れるかを検討し、配布が始まりしだい同じ手順で更新します。

保守を任せている方が確認したいこと

サーバーの保守を外部に任せている場合は、次の3点を確認すると安心です。

• 修正済みのカーネルで動いているか。「対応しました」ではなく、uname -r のバージョン番号で答えてもらう
• 再起動まで済んでいるか。カーネルは入れただけでは効かない
• 修正済みのカーネルがまだ出ていない部分はどうするか。いつ、どの手順で更新するか

FUNBREWにご相談いただける場合

FUNBREWの保守サービスでは、今回のような脆弱性への対応を、修正の有無の確認から再起動、動作の確認まで行っています。サーバーの状態が分からない、保守会社からの報告が十分か判断できないといった段階でもご相談ください。

まとめ

• 2026年11月のLinuxカーネルの脆弱性（CVE-2026-98432）は、インターネットに公開しているLinuxサーバーが基本的に対象になる
• 「修正を入れた」という通知があっても、実際に入っているとは限らない。今回は修正済みのカーネルがsecurityの配布元に載る前で、標準の自動更新では入らなかった
• 確認は uname -r のバージョン番号で行う。修正済みのカーネルが入ったうえで、再起動して初めて効く

更新を後回しにしたときに何が起きるかは、セキュリティアップデートを放置するとどうなる？にまとめています。

→ 保守のご相談はこちら