CVE-2026-98432対策の手順を示す編集部作成の説明用カバー
ノート

CVE-2026-98432対策｜Linux VPSをAIと1時間で守った手順

「VPSのデフォルト設定に重大な脆弱性」と話題になったCVE-2026-98432。影響の確認方法、修正カーネルが出る前にできる緩和策、そのまま使えるスクリプト、AIと人間の役割分担までを1本にまとめました。

2026年11月3日、SNSで「VPSのデフォルト設定に重大な脆弱性があり、影響範囲が広い」と話題になっていました。当サイトの統計用VPS（Ubuntu 24.04）で実際に影響を確認し、AI（Claude）と一緒に対処した記録です。「何の脆弱性か」「自分のサーバーは危ないのか」「何をすれば良いか」を、同じ状況の方がそのまま使える形でまとめました。

※ 本文中の <VPS>、<key>、<作業用ディレクトリ> などの <> はプレースホルダーです。ご自身の環境の値に置き換えてください。内容は2026年11月3日時点の情報です。

結論：CVE-2026-98432で今すぐやること

  • 脆弱性：CVE-2026-98432。Linuxカーネルの IPv4 TCP ハンドシェイク処理にある use-after-free で、CVSS 9.8、リモートから認証なしで攻撃できるとされています。
  • 「デフォルト設定が危ない」と言われる理由：報告された攻撃手法（エクスプロイト）の前提が MPTCP のリスナーです（コードは公開されていません）。Ubuntu は net.mptcp.enabled=1 が初期値で、Go 1.24 以降で作られたサーバーは MPTCP を自動で要求します。
  • 根本対策：ディストリビューションのカーネル更新と再起動。ただし Ubuntu 24.04 の修正版（6.8.0-149）は11月3日時点で未リリース です。
  • 今すぐできる緩和策：net.mptcp.enabled = 0 に設定、公開ポートを最小限にする、ほかの更新をすべて適用する。
  • 作業時間：調査から修正・検証まで約1時間。人間が sudo を使ったのは1回だけでした。

CVE-2026-98432とは？「デフォルト設定が危ない」と言われる理由

11月初旬、「Linux VPS に重大な脆弱性」「大手 VPS 事業者がホストを緊急再起動中」という情報が流れていました。AI に調べてもらったところ、話題の中身は次の2つでした。

CVE-2026-98432（今回の本命）

  • Linux カーネル 4.4 以降の、IPv4 TCP の接続確立処理にある use-after-free です。
  • 外部から TCP ポートに届けば、認証なしでカーネルメモリの読み書きやクラッシュが可能とされています。報告された攻撃手法は、MPTCP リスナーがあることを前提にしています（コードは公開されていません）。
  • 2026年10月5日にカーネル側で修正され、10月15日に CVE が公開されました。同じ時期に、別のカーネル脆弱性（CVE-2026-99999）への対応として全ホストを順次再起動している VPS 事業者もあります。
  • 修正済みの upstream 版は 5.10.272 / 5.15.223 / 6.1.190 / 6.6.159 / 6.12.113 などです。Ubuntu 24.04（noble）は 6.8.0-149 で対応中で、11月3日時点では未リリースです。

CVE-2026-46300（実際に悪用が確認されている脆弱性）

  • ローカルでの権限昇格の脆弱性で、米 CISA の「悪用が確認された脆弱性」リスト（KEV）に登録されています。
  • Ubuntu 24.04 では 6.8.0-124 で修正済みです。最近 apt upgrade していれば、対処済みのはずです。

「デフォルトの脆弱性」という言い方は、おそらく「Ubuntu では初期設定で MPTCP が有効」「Go 製のサーバー（Caddy、docker-proxy など）が初期設定で MPTCP を要求する」という組み合わせを指しています。

自分のVPSは影響を受けるか — 確認コマンド

AI には sudo 権限のない作業用ユーザーで SSH 接続してもらい、次の項目を読むだけで確認してもらいました。

uname -r                                   # カーネルのバージョン
cat /etc/os-release | head -2
apt list --upgradable                      # 新しいカーネルが来ているか
sysctl net.mptcp.enabled                   # 1 なら MPTCP 有効（要対処）
ss -Mln                                    # MPTCP リスナーの有無
ss -tlnp | grep -v 127.0.0                 # 外に開いているポート
ls /etc/ssh/sshd_config.d/; cat /etc/ssh/sshd_config.d/*   # SSH 設定の重ね合わせ
systemctl is-active unattended-upgrades fail2ban ufw

外側からは、パスワード認証が本当に拒否されるかも実際に試しました。

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@<VPS>
# → Permission denied (publickey) と出れば OK

チェック結果と判断

  • カーネル：Ubuntu 24.04.5、修正前のバージョン。CVE-2026-46300 は対処済み、CVE-2026-98432 は未修正でした。
  • MPTCP：net.mptcp.enabled = 1 → 無効化することにしました。
  • 公開ポート：必要最小限に絞ってあり、Web 用のポートは Cloudflare の IP 帯からの接続だけを許可していました。
  • SSH：パスワードログインと root ログインが拒否されることを実際に確認しました。
  • SSH 設定の落とし穴：/etc/ssh/sshd_config.d/ に、VPS の管理パネルが生成した PermitRootLogin yes / PasswordAuthentication yes の設定ファイルが残っていました。今は先に読み込まれる別のファイルの設定が優先されて無効でしたが、ファイル名の順序しだいで逆転します。削除することにしました。
  • 自動更新：unattended-upgrades は動いていましたが、自動再起動はしない設定でした。
  • 保留中の更新：Docker 関連などのパッケージが十数個残っていたので、適用することにしました。

ポイントは、Web 用のポートを Cloudflare の IP 帯だけに絞っておくことです。Cloudflare が TCP 接続を終端するので、外部から細工した TCP パケットを直接送れる相手が大きく減り、CVE-2026-98432 のようなリスクも下がります。VPS を Cloudflare の裏に置いている場合は、ファイアウォール（UFW など）で Cloudflare の IP 帯に限定しているかを確認しておく価値があります。

AIに任せる範囲と人間がやる範囲

作業のルールは最初に決めておきました。

  • AI は sudo 権限のない作業用ユーザーで接続します。読み取り、ファイルの配置、結果の検証まではできます。
  • 変更を伴う操作は、AI がスクリプトを書き、人間が内容を読んでから sudo で1回だけ実行します。
  • sudo のパスワードは AI に渡しません。

実際の流れは次のとおりです。

  1. AI が脆弱性を Web で調べ、Ubuntu Security Tracker で自分のバージョンの修正状況を確認する。
  2. AI が SSH で現状を確認する（前のセクションの内容）。
  3. AI が修正スクリプトを書き、手元の PC 側とサーバー側でファイルの sha256 が一致することを確認してから、サーバーの作業用ディレクトリに置く。
  4. 人間が自分のターミナルから1行だけ実行する（下のコマンド）。
  5. AI がもう一度 SSH で結果を検証する（MPTCP が 0 になったか、SSH 設定、残りの更新が 0 件か、サービスが正常に応答するか、パスワード認証が拒否されるか）。

手順4で人間が実行したのは、次の1行だけです。

ssh -t -i ~/.ssh/<key> <作業用ユーザー>@<VPS> 'sudo bash <作業用ディレクトリ>/mitigate-cve-2026-98432.sh'

途中で出た「REMOTE HOST IDENTIFICATION HAS CHANGED!」

手順4で、SSH がこの警告を出して止まりました。AI 側は以前に記録しておいた指紋で問題なく接続できていて、表示された指紋も同じでした。原因は、以前 VPS を再インストールしたときの古いホスト鍵が、手元の `~/.ssh/known_hosts` に残っていたことでした。

ssh-keygen -R <VPS の IP>     # 古い行を削除
# 再接続時に表示される指紋を、記録してある正しい指紋と照らし合わせてから yes

AI 側に正しい指紋が記録されていたので、警告をうのみにも無視にもせず判断できました。ホスト鍵の指紋は、どこかに書き留めておくのがおすすめです。

そのまま使える緩和スクリプト（Ubuntu 24.04）

何度実行しても同じ結果になるように作ってあり、失敗したステップだけ元に戻します。

注意：ステップ [2] の 99-ctrl.conf は、筆者の VPS の管理パネルが生成したファイル名です。ほかの環境では名前が違うか、存在しません。先に ls /etc/ssh/sshd_config.d/ と sshd -T で自分の環境を確認し、ファイル名を書き換えてから実行してください。

#!/usr/bin/env bash
# CVE-2026-98432 緩和 + SSH 設定の落とし穴除去 + 保留中の更新適用（Ubuntu 24.04）
set -euo pipefail
test "$(id -u)" = 0 || { echo "run with sudo"; exit 1; }
TS=$(date +%Y%m%d-%H%M%S); BK=/root/security-backup-$TS; mkdir -p "$BK"
echo "== [0] 現状"; uname -r; sysctl net.mptcp.enabled

echo "== [1] MPTCP を無効化（報告された攻撃手法の前提条件を潰す）"
install -m 644 /dev/stdin /etc/sysctl.d/90-mptcp-off.conf <<'S'
# CVE-2026-98432 mitigation: no MPTCP listeners on this host
net.mptcp.enabled = 0
S
sysctl -q -p /etc/sysctl.d/90-mptcp-off.conf
test "$(sysctl -n net.mptcp.enabled)" = 0 && echo "OK net.mptcp.enabled=0"

echo "== [2] sshd: 管理パネルが生成した緩い設定ファイルを除去（ある場合）"
F=/etc/ssh/sshd_config.d/99-ctrl.conf      # ← 自分の環境のファイル名に書き換える
if [ -f "$F" ]; then
  cp -a "$F" "$BK/"; rm -f "$F"
  if sshd -t; then systemctl reload ssh; echo "OK removed $F (backup: $BK)"
  else cp -a "$BK/$(basename $F)" "$F"; echo "sshd -t failed, restored"; exit 1; fi
else echo "already absent"; fi
sshd -T 2>/dev/null | grep -E '^(passwordauthentication|permitrootlogin|kbdinteractiveauthentication|pubkeyauthentication) '

echo "== [3] カーネル更新の確認（6.8.0-149 以上なら入れる）"
apt-get update -qq
CAND=$(apt-cache policy linux-image-generic | awk '/Candidate:/{print $2}')
echo "installed: $(dpkg-query -W -f='${Version}' linux-image-generic)  candidate: $CAND"
if dpkg --compare-versions "$CAND" ge 6.8.0-149; then
  DEBIAN_FRONTEND=noninteractive apt-get install -y -qq linux-generic linux-image-generic linux-headers-generic
  echo ">>> 新カーネル導入済み。再起動が必要: sudo reboot"
else
  echo "まだ未リリース。unattended-upgrades が届き次第入れる → 入ったら sudo reboot"
fi

echo "== [4] 他のセキュリティ更新（docker 等。コンテナは短時間再起動する）"
DEBIAN_FRONTEND=noninteractive apt-get -y -qq -o Dpkg::Options::=--force-confold upgrade
docker ps --format '{{.Names}} {{.Status}}' 2>/dev/null || true

echo "== [5] 公開面の再確認"
ufw status verbose | head -20
ss -tlnp | grep -v 127.0.0
ls /var/run/reboot-required 2>/dev/null && echo ">>> REBOOT REQUIRED" || echo "no reboot flag"
echo "== DONE $TS  backup=$BK"

実行後の確認（sudo なしでできます）：

sysctl net.mptcp.enabled            # 0 になっていること
ls /etc/ssh/sshd_config.d/          # 緩い設定ファイルが消えていること
apt list --upgradable               # 何も表示されないこと
curl -s -o /dev/null -w '%{http_code}\n' https://<自分のサービス>/<ヘルスチェック用のパス>   # 200

修正カーネルが出たらやること

  • Ubuntu の修正カーネル（6.8.0-149）が出たら、同じスクリプトをもう一度実行して `sudo reboot` します。それまでは「緩和済み・根本修正待ち」の状態です。
  • 修正状況は Ubuntu Security Tracker の CVE-2026-98432 のページ で、noble の linux が「Released」になっているかで確認できます。
  • unattended-upgrades は新しいカーネルを入れてくれますが、再起動はしません。自動で再起動させたい場合は、/etc/apt/apt.conf.d/50unattended-upgrades の Automatic-Reboot "true" と Automatic-Reboot-Time（バックアップが終わった後の時刻）を設定します。

まとめ：今回の教訓

  1. 話題の脆弱性は、まず CVE 番号に落とし込む。番号が分かれば、ディストリビューションの Security Tracker で「自分のバージョンは修正済みか」がすぐ分かります。
  2. 修正版が出ていなくても、緩和策はある。前提条件（今回は MPTCP）をなくす、公開ポートを減らす、ほかの更新を全部当てる。
  3. 公開ポートを Cloudflare の IP 帯に限定しておくと、TCP レベルの脆弱性の多くはそもそも届きません。
  4. SSH 設定は `sshd -T` で実際に効いている値を見る。sshd_config.d/ に VPS の管理パネルがファイルを置くことがあり、ファイル名の順序で結果が変わります。
  5. AI に sudo を渡さなくても、ほとんどの作業を任せられる。調査・診断・スクリプト作成・配置・検証は AI、変更の実行は人間が1行。責任の境界がはっきりし、記録も残ります。
  6. ホスト鍵の指紋を記録しておく。「HOST IDENTIFICATION HAS CHANGED」が出たときに、慌てず判断できます。

参考リンク