Linuxカーネル脆弱性CVE-2026-98432｜VPSで今やること3つ

2026年10月15日、Linuxカーネル（Linuxの中核となるプログラム）に見つかった脆弱性CVE-2026-98432が公表されました。ログイン不要で、ネットワーク越しに届く通信だけでサーバーを乗っ取られるおそれがあるもので、深刻度はCVSS v3.1で9.8（10点満点）と評価されています。この記事では、VPSやクラウドでサーバーを動かしている中小企業の担当者に向けて、対象になるか、今なにをすればいいかを、2026年10月31日時点で確認できた一次情報をもとに整理します。

結論：CVE-2026-98432で今やること3つ（2026年10月31日時点）

何が起きたか。LinuxカーネルのIPv4のTCP処理に、解放済みのメモリを使ってしまう不具合（use-after-free）が見つかりました。Linuxカーネルの脆弱性を採番する組織（Linux CNA）は、認証なしでネットワークから攻撃でき、攻撃の難しさは低いとして、CVSS v3.1で9.8（Critical）と評価しています。

誰が対象か。Linuxカーネル4.4以降を使い、外部からの接続を受け付けているサーバーです。中小企業で多いのは、さくらのVPS・ConoHa VPS・AWS（Amazon Lightsail・EC2）などで、OSから自分で管理しているサーバーです。共用のレンタルサーバーは、カーネルの更新を事業者が行います。

今やることは次の3つです。

1. 自社で管理しているLinuxサーバーを洗い出す。制作会社や保守会社に任せているサーバーも含めます。分からなければ、契約しているサーバーの一覧から確認します。
2. OSの配布元が修正済みのカーネルを出しているかを確かめ、出ていれば更新して再起動する。カーネルは再起動しないと新しいものに切り替わりません。Ubuntuは10月30日時点で、サポート中の全版が「修正作業中」で、修正済みのカーネルはまだ出ていません。
3. 修正が出るまでは、外に開いている入口を減らしておく。使っていないサービスを止め、管理用の接続（SSHなど）は接続元を絞ります。ただし、これは完全な対策ではありません。Webサイトのように誰からの接続も受ける入口は残るので、修正済みカーネルへの更新が唯一の対策です。

CVE-2026-98432とは：何が危ないのか

修正のもとになったLinuxの変更（コミット）の題は「ipv4: free inet_opt and ireq_opt after an RCU grace period」です。TCPの接続を受け付ける途中で、通信に付いている「IPオプション」という付加情報を保存したメモリが、別の処理で解放された後にも読まれてしまう、という不具合です。

発見者は「認証なしでroot権限を取れた」と公表

この脆弱性を見つけて報告したAnthropicは、10月27日の研究レポートで、MPTCP（複数の通信経路を束ねるTCPの拡張）で接続を待ち受けるLinuxサーバーに対し、認証なしでroot（管理者）権限のコマンドを実行できたと公表しています。レポートによると、検証ではカーネルの防御を外すまでに約48分、そこからコマンドの実行まで約5分かかりました。また、上流で修正され、保守中のすべての安定版カーネルに取り込まれたとしています。

一方で、CVEの説明や修正の内容にMPTCPの記載はありません。「MPTCPを使っていないから安全」と判断できる公式の根拠は、この記事の時点では見当たりません。

修正済みのカーネルの版と、配布元の対応状況

Linuxカーネルの上流（開発元）では、次の版で修正されています（CVEの記録による）。

ただし、VPSやクラウドで使うUbuntuなどのOSは、上流の版をそのまま使わず、配布元が修正を取り込んだ独自のカーネルを配ります。「uname -r で出た数字が上の表より小さいから未対応」とは限らず、逆に数字が大きくても修正済みとは限りません。判断は、使っているOSの配布元の情報で行ってください。

Ubuntuの状況（10月30日更新時点）

出典はUbuntuのセキュリティ情報（CVE-2026-98432）です。修正済みのカーネルが出ると、このページの状況が「Fixed」に変わります。

Debian・RHEL系・Amazon Linuxなど

Debian、Red Hat Enterprise Linux（AlmaLinux・Rocky Linuxなどの互換OSを含む）、SUSE、Oracle Linux、Amazon Linuxも、それぞれ公式ページで対応状況を公開しています。この記事の作成時点では、これらのページを直接確認できなかったため、状況は書いていません。使っているOSの公式ページで確かめてください。

• Debian Security Tracker（CVE-2026-98432）
• Red Hat CVEページ（CVE-2026-98432）
• Amazon Linux Security Center（CVE-2026-98432）
• SUSE CVEページ（CVE-2026-98432）
• Oracle Linux CVEページ（CVE-2026-98432）

サーバーの種類別：自社がやること

実務でよく見るのは、「サイトを作ったときに制作会社がVPSを用意し、その後は誰も更新していない」というケースです。誰がサーバーを管理しているかが曖昧なら、今回をきっかけに決めておくと、次の緊急更新で慌てずに済みます。

VPS・クラウドでの確認と更新の手順

1. 今のカーネルの版を見る。サーバーにログインし、uname -r を実行します。表示された版を、配布元の情報と照らし合わせます。
2. 配布元の修正済みカーネルが出ているかを確かめる。上の配布元のページで、自分のOSの版が「修正済み」になっているかを見ます。
3. 出ていれば更新する。UbuntuやDebianなら sudo apt update のあと sudo apt upgrade、RHEL系やAmazon Linuxなら sudo dnf update kernel が基本です。更新の前にバックアップやスナップショットを取っておきます。
4. 再起動し、版が変わったことを確かめる。再起動後にもう一度 uname -r を実行し、新しいカーネルで動いているかを見ます。サイトや業務のシステムが正常に動いているかも確認します。

再起動でサイトが短時間止まるので、アクセスの少ない時間帯を選んでください。複数のサーバーがある場合は、外部に公開しているものから先に進めます。

修正が出るまでにできること（完全な対策ではない）

修正済みのカーネルが出るまでの間に入口を減らす方法として、次のようなものがあります。いずれも攻撃を受ける機会を減らすだけで、完全な対策ではありません。

• 使っていないサービス（古い管理画面、試しに入れたソフトなど）を止める
• SSHなどの管理用の入口は、VPSやクラウドの管理画面のファイアウォール（パケットフィルター・セキュリティグループ）で接続元を自社のIPアドレスに絞る
• 配布元のページを毎日確認し、修正済みカーネルが出たらすぐに更新できるよう、作業の段取りと担当者を決めておく

Webサイト（80番・443番ポート）は誰からの接続も受け付ける必要があるので、この方法では守れません。この記事で確認した公式の情報（CVEの記録・Ubuntu）には、特定の設定変更で防げるという回避策は書かれていません。

サーバーまわりの更新を自社だけで回すのが難しい場合は、保守ごと任せられる形にしておくのも一つの手です。Mihataでは、中小企業のホームページを、サーバーの準備から公開後の保守まで含めて制作しています。記事の途中で恐縮ですが、よろしければご覧ください。

まとめ：まず「自社のLinuxサーバーは誰が更新するか」を確かめる

CVE-2026-98432は、認証なしで外部から攻撃できるLinuxカーネルの脆弱性です。10月31日時点で、CISAのKEVには載っておらず、発見者のAnthropicは検証環境での攻撃の成功を公表しています。共用のレンタルサーバーなら事業者の対応を確認し、VPSやクラウドを自社で管理しているなら、配布元の修正済みカーネルが出しだい更新して再起動してください。

同じ時期にはPHPの重大な脆弱性への対応も続いています。レンタルサーバーやVPSの利用者が確認することはレンタルサーバー別のPHP脆弱性への対応状況に、普段の備えは中小企業のホームページで最低限やるセキュリティ対策にまとめています。

自社のサーバーがどこにあり、誰が更新しているのか分からない、という段階からでもかまいません。気になることがあれば、お気軽にご相談ください。