CVSS 9.8のLinuxカーネル脆弱性CVE-2026-98432が公表されました。Ubuntuはまだ修正版未リリース。自サーバーの確認方法と、修正版が出た瞬間に自動適用される体制の整え方を解説します。
まず最初に知っておきたい3つの事実
管理しているLinuxサーバーが今、危険な状態かもしれません。
Linuxカーネルに深刻な脆弱性CVE-2026-98432が報告されています。重要度はCVSS v3スコアで**9.8（Critical）**と最高クラスです。さらに深刻なのが、Ubuntu（26.04 / 24.04 / 22.04 LTS）はいずれも2026年10月30日時点でまだ修正版がリリースされていないという点です。つまり、今この瞬間に apt upgrade を実行しても、この脆弱性は塞がりません。
ただし、「修正版が出たらすぐ自動で適用され、その夜のうちに再起動まで完了する」という体制は今日から整えられます。この記事では自分のサーバーの状態確認から、その体制づくりまでを順を追って解説します。
この脆弱性の正体：何が起きているのか
use-after-free（解放後使用）とは
CVE-2026-98432の原因は、LinuxカーネルのIPv4 TCP処理における**use-after-free（UAF）**と呼ばれる脆弱性です。Ubuntuのセキュリティトラッカーには次のように説明されています。
接続要求から子ソケットを作る際、IPオプションを正しくコピーせず所有権だけを移している。その後、別のCPUで処理される再送SYNがSYN-ACKを組み立てようとするとき、すでにメモリから解放されたIPオプションを読み取ってしまう競合（race condition）が発生する。この ip_options_build() での解放済みメモリへのアクセスがUAFの本体です。
修正の内容は、inet_sock_destruct() と tcp_v4_reqsk_destructor() において、IPオプションの解放処理を kfree() から kfree_rcu() に変更すること。リクエストソケットのマイグレーション時にも同様の問題があり、そちらも対応対象とされています。
「MPTCPを無効にすれば安全」は誤りです
重要な誤解：MPTCPを無効化しても、この脆弱性への対策にはなりません。
2026年10月27日、Anthropicが「MPTCPの待ち受けサーバーを標的として、AIが作成した攻撃コードで認証なしに遠隔からroot権限のコマンドを実行できた」と発表しました。この報道を受けて「MPTCPを切れば安全では？」と考える方もいますが、それは誤りです。
この脆弱性の原因はIPv4のTCP処理そのものにあります。 MPTCPは実証実験で狙われた「対象」に過ぎず、IPv4でTCPの待ち受けがあるサーバーは対象になりえます。net.mptcp.enabled = 0 を設定してMPTCPを無効にしても、通常のTCPの待ち受けは残ります。ss -Mln でMPTCPの待ち受けが空であっても、それは安心の根拠にはなりません。
なお、IPv6は今回の1つ目の問題（UAF）の対象外ですが、関連するIPv6のマイグレーション問題は別途対応とされています。
ディストリビューション別の現在地（2026年10月30日時点）
| OS | 状態 | 準備中バージョン | 今すぐ更新可能？ |
|---|---|---|---|
| Ubuntu 26.04 LTS | Vulnerable, work in progress | 7.0.0-43.43 | |
| Ubuntu 24.04 LTS | Vulnerable, work in progress | 6.8.0-149.149 | |
| Ubuntu 22.04 LTS | Vulnerable, work in progress | 5.15.0-203.213 | |
| Ubuntu 20.04 / 18.04 / 16.04 | Vulnerable | 記載なし | |
| Amazon Linux 2（全カーネル） | Pending Fix | — | |
| Amazon Linux 2023（標準kernel） | Pending Fix | — | |
| Amazon Linux 2023（kernel6.12） | 修正済み（ALAS2023-2026-3335） | — | |
| Amazon Linux 2023（kernel6.18） | 修正済み（ALAS2023-2026-3251） | kernel6.18-6.18.56-125.164.amzn2023 |
Ubuntuは全LTSバージョンで修正版が準備中であることが確認されていますが、リリースは未完了です。Amazon Linux 2023のkernel6.12とkernel6.18については、すでに修正版がリリースされており、今すぐ更新が可能です。
自分のサーバーの状態を確認する手順
ステップ1：現在動いているカーネルを確認する
uname -r
出力例（Ubuntu 22.04）：
5.15.0-198-generic
uname -r に出るのは 5.15.0-198 のような形で、トラッカーに載るパッケージのバージョン（5.15.0-203.213 など）とは表記が少し違います。インストール済みのカーネルパッケージは次のコマンドで確認できます。
dpkg -l 'linux-image-*' | grep ^ii
修正版かどうかは、トラッカーで「Released」と表示されたバージョンと照合してください。2026年10月30日時点では、Ubuntuの各LTSはまだ「work in progress」です。
ステップ2：再起動待ちかどうかを確認する
cat /var/run/reboot-required
ファイルが存在すれば「カーネルは更新されたが、まだ古いカーネルで動いている」状態です。更新が適用されても再起動しないと意味がありません。 このファイルが存在するにもかかわらず長期間再起動されていないサーバーは、要注意です。
ステップ3：自動更新・自動再起動の設定を確認する（Ubuntu）
apt-config dump | grep Unattended-Upgrade
Unattended-Upgrade::Automatic-Reboot "false"; となっていれば、カーネルが更新されても再起動は自動では行われません。
ステップ4：MPTCPの待ち受けを確認する（参考情報として）
ss -Mln
繰り返しになりますが、この結果が空であっても脆弱性のリスクがなくなるわけではありません。あくまで参考情報として確認してください。
ステップ5：Amazon Linuxのカーネル系統を確認する
rpm -qa 'kernel*'
出力に kernel6.18 や kernel6.12 が含まれていれば、今すぐ修正版への更新が可能です。
Amazon Linux 2023では、さらに以下のコマンドで新しいリリース版の有無を確認します：
dnf check-release-update
修正版が出るまでにやること：「その夜に自動で塞がる」体制づくり
Ubuntu：自動再起動の設定を今すぐ入れる
Ubuntuの unattended-upgrades はデフォルトでカーネル更新後の自動再起動が無効です。修正版がリリースされた瞬間に自動インストールされても、再起動が行われなければ古いカーネルのまま動き続けます。
/etc/apt/apt.conf.d/ に設定ファイルを1つ追加します。既存の 50unattended-upgrades を直接書き換えるより、別ファイルに分けたほうがパッケージ更新時の差分確認で迷いません。
sudo tee /etc/apt/apt.conf.d/99-auto-reboot.conf <<'EOF'
// 再起動が必要な更新があったときだけ、指定時刻に自動で再起動する
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
EOF
再起動が必要な更新がない日は再起動しません。
タイムゾーンの落とし穴： この時刻はサーバーのタイムゾーンで解釈されます。サーバーがUTCで動いている場合、日本時間の03:30に再起動させたいなら "18:30" と設定する必要があります（UTC 18:30 = JST 翌03:30）。まずサーバーのタイムゾーンを timedatectl で確認してください。
設定後、反映されているか確認します：
apt-config dump | grep Unattended-Upgrade
Amazon Linux 2023：kernel6.12または6.18系なら今すぐ更新できる
kernel6.12またはkernel6.18を使用しているサーバーは、修正版がすでにリリース済みです。以下のコマンドで更新できます：
sudo dnf --releasever=latest upgrade kernel6.18
# または
sudo dnf --releasever=latest upgrade kernel6.12
更新後は再起動を忘れずに：
sudo reboot
再起動後、uname -r でバージョンを確認します。kernel6.18であれば 6.18.56-125.164.amzn2023 以上になっていれば成功です。
Amazon Linux 2023の重要な落とし穴： AL2023はリポジトリがAMIのリリース版に固定される仕組みになっています。通常の dnf upgrade を実行しても、AMIリリース後に公開された修正パッケージは取得対象になりません。必ず --releasever=latest オプションを付けるか、dnf check-release-update で新しいリリース版の有無を確認してください。dnf-automatic を設定しているだけでは、この固定のせいで新しい修正が自動的に取り込まれない場合があります。
Amazon Linux 2（全系統）・AL2023標準kernel：修正版待ち
2026年10月30日時点では「Pending Fix」のため、修正版のリリースを待つ必要があります。Ubuntuと同様に、各トラッカーを定期的に確認し、リリースが確認できたら速やかに適用・再起動を行う体制を整えておいてください。
弊社で実際に見つかった2つの落とし穴
ここからは、弊社が管理している複数のサーバーで今回の脆弱性対応の過程で実際に発見した問題を共有します。
落とし穴①：「自動更新は有効」なのに古いカーネルで数週間動き続けていた
弊社が管理しているUbuntuサーバーの中に、unattended-upgrades による自動更新は有効になっているにもかかわらず、すでにインストールされている新しいカーネルが数週間にわたって使われていなかったサーバーが存在しました。
原因はシンプルです。自動再起動を設定していなかったため、カーネルは更新されても再起動されず、古いバージョンで動き続けていたのです。
「自動更新を設定した＝安全」という思い込みは危険です。自動更新と自動再起動はセットで設定する必要があります。
落とし穴②：AL2023で自動更新が未設定かつリリース版固定で修正版が見えなかった
弊社が管理するAmazon Linux 2023のサーバーで、そもそも自動更新が設定されておらず、さらにリリース版が固定されたままだったため、kernel6.18の修正版パッケージが存在しているにもかかわらず dnf upgrade の対象に現れないという状況がありました。
dnf check-release-update を実行して初めて新しいリリース版の存在に気づき、--releasever=latest を付けることで修正版が取得できることを確認しました。このサーバーには、毎日深夜に --releasever=latest でセキュリティ更新を入れ、再起動が必要なときだけ再起動する設定を入れています。AL2023を使用している方は、まずカーネル系統の確認と dnf check-release-update の実行を強くおすすめします。
今すぐ確認できるチェックリスト
まとめと次のステップ
CVE-2026-98432は、認証なしにリモートからroot権限を奪取できる可能性が実証された、非常に深刻な脆弱性です。そしてUbuntuユーザーにとって最も重要な事実は、2026年10月30日時点では修正版がまだリリースされていないという点です。
今できる最善の行動は次の3つに集約されます。
- 今日、自動再起動の設定を入れる（Ubuntu）
- AL2023でkernel6.12/6.18系なら今すぐ更新する
- 各トラッカーをブックマークし、修正版のリリースを見逃さない
修正版がリリースされた瞬間に自動で適用され、指定した時間に再起動まで完了する体制ができていれば、対応の遅れによるリスクを最小化できます。「修正版が出てから考える」では遅すぎます。体制を整えるのは、修正版が出る前の今です。
弊社では管理サーバーの確認・設定見直しをすでに進めています。ご自身での確認が難しい場合や、管理体制の整備についてご相談があれば、お気軽にファイブナインデザインへお問い合わせください。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
参考リンク
本記事の情報は2026年10月30日時点のものです。脆弱性の状況は日々変化するため、必ず各公式トラッカーで最新情報をご確認ください。
