先日、このブログのサーバーを Ubuntu 22.04 から 24.04 に上げました（アップグレードの記事）。 数日たったのでログを確認し、あわせて Ubuntu のセキュリティ情報を見ていたところ、CVE-2026-98432 という Linux カーネルの脆弱性が公開されていました。
この記事では、この脆弱性が自分のサーバーに関係あるかを確認したことと、脆弱性対応を「どこまでやるか」について今の自分の考えをまとめます。セキュリティを勉強し始めたばかりなので、あくまで現時点での考えです。
CVE-2026-98432 の概要
Ubuntu のページ（ubuntu.com/security/CVE-2026-98432）によると、内容は次のとおりです。
- 対象：Linux カーネルの IPv4 の TCP 処理
- 中身：接続を始めるとき（SYN を受けて SYN-ACK を返す処理）に、IP オプションのデータを解放したあとも別の処理がそれを使ってしまうことがある（use-after-free）
- 深刻度：Ubuntu の優先度は High、CVSS 3.1 は 9.8
- Ubuntu 24.04 の状態：修正は作業中で、まだ配布されていない（2026年10月29日時点）
カーネルの問題なので、Apache や WordPress の設定では対処できません。
自分のサーバーが対象か確認する
Ubuntu には、特定の CVE に対して自分のサーバーが影響を受けるかを判定するコマンドがあります。
sudo pro fix CVE-2026-98432結果（説明文の部分は省略）：
1 affected source package is installed: linux(1/1) linux:A fix is coming soon. Try again tomorrow.1 package is still affected: linux✘ CVE-2026-98432 is not resolved.対象でした。ただし修正版はまだ出ていないので、現時点でできることはありません。
どこまで対応するか
CVE は毎日何十件も公開されています。すべてを詳しく調べて対応するのは、個人では続けられないと考えました。一方で、何もしないわけにもいきません。
そこで、次のように分けて考えることにしました。
普段：仕組みに任せる
- セキュリティ更新は自動で入るようにしておく
- カーネルの更新に備えて、再起動も自動にしておく
- 外から触れる入口を減らしておく（使っていない機能は止める、管理画面の入口を守る、SSH は鍵認証だけにする）
- ときどきログを見る
これで、多くの脆弱性は特に意識しなくても修正が当たる状態になると考えています。
個別に判断する：4つの質問
| 質問 | 「いいえ」なら |
|---|---|
| ① そのソフトを使っているか | 関係なし |
| ② 外から攻撃が届くか | 急がない |
| ③ 実際に悪用されているか | 自動更新に任せる |
| ④ 修正や回避策はあるか | 回避策で様子を見る／修正を待つ |
③ は、米国の CISA が公開している KEV（実際に悪用が確認された脆弱性のリスト）に載っているかで判断します。
①〜③ がすべて「はい」ならその日のうちに対応し、それ以外は自動更新に任せる、という線引きにしました。
CVSS の点数だけで判断しないようにしています。9.8 でも攻撃の条件が厳しいものがあり、逆に点数が低くても実際に広く悪用されているものもあるためです。
今回の件に当てはめる
| 質問 | 今回 |
|---|---|
| ① 使っているか | はい（Ubuntu 24.04 のカーネル） |
| ② 外から届くか | はい（接続を始める処理が入口） |
| ③ 悪用されているか | 確認した範囲ではされていない |
| ④ 修正はあるか | まだ（近日公開） |
説明文によると、IP オプション付きの接続要求とその再送が、別々の CPU で同時に処理されたときにだけ起きる問題です。狙って起こすのは難しい部類だと判断しました。
そのため今回は、「修正が出たら数日以内に入れて再起動する」で十分と考えました。あとは、それが自分の記憶に頼らず実行されるように設定しておきます。
やったこと①：自動更新が動いているか確認
Ubuntu Server には unattended-upgrades という自動更新の仕組みが最初から入っています。有効になっているかを確認しました。
cat /etc/apt/apt.conf.d/20auto-upgradesAPT::Periodic::Update-Package-Lists "1";APT::Periodic::Unattended-Upgrade "1";両方 "1" なので有効です。実際に入った更新はログで確認できます。
sudo tail -n 20 /var/log/unattended-upgrades/unattended-upgrades.log毎朝自動で実行されていて、数日前には libbrotli1（圧縮ライブラリ）のセキュリティ更新が入っていました。
やったこと②：自動再起動をオンにする
カーネルは更新しても、再起動するまでは古いものが動き続けます。そして Ubuntu Server の自動再起動は、初期状態ではオフです。
勝手に再起動すると困るサーバーが多いため、再起動は人が判断する前提になっているようです。再起動が必要なときは、ログイン時に *** System restart required *** と表示されます。
このブログは深夜に数十秒止まっても問題ないので、オンにしました。
echo 'Unattended-Upgrade::Automatic-Reboot "true";Unattended-Upgrade::Automatic-Reboot-Time "(再起動する時刻)";' | sudo tee /etc/apt/apt.conf.d/52auto-reboot時刻は "04:00" のように書きます。設定が読み込まれたかは次のコマンドで確認できます。
apt-config dump | grep -i automatic-reboot再起動するのは「再起動が必要な更新が入ったとき」だけで、毎日再起動するわけではありません。
やったこと③：再起動後にサービスが起動するか確認
前回のアップグレードでは、再起動後に Apache が止まっていました。自動で再起動したあとに必要なサービスが起動するかも確認しておきます。
systemctl is-enabled apache2 fail2ban sshenabledenableddisabledssh が disabled になっていますが、これは正常です。 Ubuntu 24.04 から、SSH は「ソケット起動」という方式に変わっています。普段は ssh.socket が 22 番ポートで待ち受け、接続が来たときに ssh.service を起動します。確認するのはソケットの方です。
systemctl is-enabled ssh.socketenabledここで ssh.service を enable すると、ソケットとポートを取り合って接続できなくなることがあるので、そのままにしておきます。
修正が出たら
基本は自動更新と自動再起動に任せますが、数日おきに次のコマンドで状況を確認します。
sudo pro fix CVE-2026-98432「resolved」になっていれば対応完了です。手動で反映する場合は次のとおりです。
sudo apt update && sudo apt upgradecat /var/run/reboot-requiredsudo rebootなお、再起動せずにカーネルへ重要な修正を当てる Livepatch というサービスもあります（Ubuntu Pro に登録すると個人は無料で使えます）。止められないサーバーではこちらが選択肢になると思います。
まとめ
- CVE-2026-98432 は Ubuntu 24.04 のカーネルの脆弱性で、自分のサーバーも対象だった（修正待ち）
sudo pro fix CVE番号で、自分のサーバーが影響を受けるか判定できる- すべての CVE を追うのではなく、普段は自動更新に任せ、個別の判断は4つの質問で行うことにした
- CVSS の点数だけでなく、「使っているか・届くか・悪用されているか・修正はあるか」で判断する
- カーネルは再起動しないと切り替わらない。Ubuntu Server の自動再起動は初期状態ではオフ
- Ubuntu 24.04 の SSH はソケット起動。
sshが disabled でもssh.socketが enabled なら正常
このブログを始めたきっかけは仕事で対応した PHP の脆弱性でした。そのときは決められた手順に沿って対応しただけでしたが、今回は「どこまでやるか」を自分で決めるところまで考えてみました。
この基準は今の時点のもので、勉強を進めながら見直していくつもりです。修正版が出たら、その後の対応も追記します。
