Linuxカーネルの脆弱性CVE-2026-98432｜対象の確認方法と更新手順【2026年11月】

📖 読了時間：約15分

Linuxカーネルの脆弱性CVE-2026-98432とは、IPv4のTCP接続を受け付ける処理にある不具合のことです。2026年10月15日に公表され、ログインなどの認証も利用者の操作もなく、外部からの通信だけで攻撃を試みられるため、Red Hatは深刻度を「Critical」（CVSS 9.8）としています。

Webサーバーやデータベースなど、外から接続を受け付けるLinuxのサーバーは広く対象になりえます。Red Hat Enterprise Linux（RHEL）、Debian、Amazon Linuxはすでに修正済みのカーネルを公開しており、Ubuntuは11月4日時点で修正版を準備している段階です。

以下では、仕組み、ディストリビューション別の状況、対象かを確かめる手順、対応方法と暫定対策、経歴での伝え方の順に解説します。内容は2026年11月4日時点の公開情報にもとづいています。

この記事を読めば、担当しているLinuxサーバーが対象かどうかを判断し、何から手を付ければよいかが分かります。対応を終えたら、無料のスキルログに作業の内容を記録して、経歴として残しておきましょう。

TCPの接続は、相手からの接続要求（SYN）に応答（SYN-ACK）を返して始まります。この処理と、同じ接続の再送された要求の処理が別々のCPUで同時に進むと、まだ使っている途中のデータが解放されてしまうことがあります。解放済みのメモリを読み書きしてしまうため、システムの停止やメモリの破壊につながります。

項目	内容
CVE番号	CVE-2026-98432
公表日	2026年10月15日
深刻度	CVSS v3.1で9.8（Red Hat・カーネルのCVEチームの評価）
攻撃の条件	ネットワーク経由、認証不要、利用者の操作不要
起きうること	システムの停止、メモリの破壊、リモートからのコード実行
対象の通信	IPv4のTCP（IPv6は主な問題の対象外）
確実な対策	修正済みカーネルへの更新と再起動

なぜ「Critical」と評価されているのか

Red Hatは、特別な設定をしていない通常のサーバーでもTCPの接続を受け付けている限り攻撃の経路になり、ローカルの権限も利用者の操作もいらない点を理由に挙げています。確実にプログラムを実行させるには細かい制御が必要としつつも、前提条件がないことから評価を引き上げています。

発見の経緯と悪用の状況

この脆弱性は、AI企業のAnthropicが自社のAIを使った脆弱性探索の中で見つけたものです。同社の公開資料では、MPTCP（複数の経路を束ねるTCPの拡張）で接続を待ち受けているサーバーに対し、認証なしで管理者権限のコマンドを実行できることを検証で確かめたとしています。米国CISAの「悪用が確認された脆弱性」の一覧には、11月3日時点で載っていません。ただし、攻撃の方法が具体的に説明されているため、早めの更新が必要です。

カーネルの版の数字はディストリビューションごとに付け方が違うため、各社が公開している「修正済みの版」と比べて判断します。11月4日時点の主な状況は次のとおりです。

ディストリビューション	状況	修正済みの版（以降なら対応済み）
RHEL 10	修正済み（11月1日、RHSA-2026:93413）	kernel-6.12.0-211.72.1.el10_2
RHEL 9	修正済み（11月1日、RHSA-2026:93412）	kernel-5.14.0-687.64.1.el9_8
RHEL 8	修正済み（11月1日、RHSA-2026:93414）	kernel-4.18.0-553.182.1.el8_10
RHEL 6・7	対象外	―
AlmaLinux 8〜10	修正済み（11月2日から通常のリポジトリ）	RHELと同じ版
Debian 12（bookworm）	修正済み	6.1.190-1
Debian 13（trixie）	修正済み	6.12.113-1
Amazon Linux 2023・2	修正済み（10月24日〜30日）	各アドバイザリーで確認
Ubuntu 22.04・24.04ほか	修正版を準備中（pending）	公開を待つ

まだ修正が出ていないもの

Red Hatの情報では、RHEL 9のリアルタイム向けカーネル（kernel-rt）と、OpenShift 4・5で使うRHCOSは、11月4日時点で「影響あり」のままです。Ubuntuは主要なカーネルのパッケージで修正版を準備中で、20.04は修正が必要と表示されています。

コンテナやクラウドのサーバーの場合

コンテナはホストのカーネルを共有しているため、コンテナのイメージを作り直しても解決しません。更新が必要なのはホスト側のカーネルです。Kubernetesのマネージドサービスなどでノードを提供元が管理している場合は、提供元の案内に従ってノードを入れ替えます。

• 動いているカーネルの版を uname -r で確かめる
• インストール済みのカーネルと、更新できる版を確かめる
• ディストリビューションのセキュリティ情報で、CVE番号ごとの修正状況を確かめる

動いているカーネルの版を確かめる

uname -r で表示されるのが、いま実際に動いているカーネルです。新しいカーネルをインストールしても、再起動するまでは古いカーネルのまま動いています。インストール済みの一覧は、RHEL系なら rpm -q kernel、Debian・Ubuntuなら dpkg -l | grep linux-image で確かめられます。

更新できる版を確かめる

RHEL系は sudo dnf check-update kernel（RHEL 7以前やAmazon Linux 2は yum）、Debian・Ubuntuは sudo apt update のあとに apt list --upgradable で、配布されている新しい版を確かめます。修正済みの版が表示されれば、更新の準備ができています。

MPTCPを使っていないかも見ておく

公開されている攻撃の検証は、MPTCPで待ち受けているサーバーを対象にしていました。ss -Mlnt で、MPTCPで待ち受けているポートがあるかを確かめられます。Go 1.24以降で作ったプログラムは、Linuxで待ち受けるときにMPTCPが初期設定で有効になる点にも注意が必要です。ただし、MPTCPを使っていなくても対象外とは言えません。

• 影響調査：外から接続を受け付けるLinuxサーバーの一覧と、カーネルの版を洗い出す
• 優先順位：インターネットに公開しているサーバーから先に対応する
• 報告：対象の範囲と、再起動の予定を関係者に伝える
• 適用：修正済みカーネルに更新し、再起動する
• 確認：再起動後に uname -r で版を確かめ、サービスの動作とログを見る

環境	更新のコマンド（例）	注意点
RHEL 8〜10・AlmaLinux	sudo dnf upgrade kernel → sudo reboot	needs-restarting -r で再起動が必要か確かめられる
Debian	sudo apt update && sudo apt upgrade → sudo reboot	新しいカーネルで起動したかを確かめる
Amazon Linux	sudo dnf upgrade kernel（AL2は yum）→ 再起動	AL2のカーネル5.10・5.15などの追加パッケージも確かめる
Ubuntu	修正版の公開後に apt で更新 → 再起動	公開まではこの後の暫定対策で危険を下げる

再起動の計画を先に立てる

カーネルの更新は、再起動しないと反映されません。冗長化しているサーバーは1台ずつ切り離して再起動し、1台構成のサーバーは停止できる時間帯を関係者と決めておきましょう。

すぐに更新できないときの暫定対策

Ubuntuの公式情報には、IPオプションの付いたIPv4のTCPの通信を破棄するnftablesのルールが載っています。ただし、危険を下げるだけで完全には防げず、IPオプションを使う通信は通らなくなります。コンテナが別のネットワークを持つ場合は、そちらにも設定が必要です。

• ルールの中身は ip protocol tcp ip hdrlength > 5 counter drop（IPヘッダーが標準より長い＝オプション付きのTCPを破棄）
• Go製のサーバーは、環境変数 GODEBUG=multipathtcp=0 でMPTCPを止められる（Go公式は「最善の対策はカーネルの更新」としている）
• 修正済みカーネルで起動したら、暫定のルールは外してよい

影響調査から再起動の調整、更新後の確認までを担当した経験は、インフラの運用やセキュリティ対応の実績になります。作業を終えたら、内容を忘れないうちに記録しておきましょう。

カーネルの更新は、台数が多いほど再起動の調整や確認の段取りが必要になる仕事です。インフラの仕事の全体像はインフラエンジニアの仕事内容で、運用の経験をセキュリティの仕事に活かす方法はセキュリティエンジニアへのキャリアチェンジで紹介しています。

書き方	例
伝わらない例	Linuxサーバーの保守を担当。カーネルのアップデートを実施
伝わる例	Linuxカーネルの緊急脆弱性（CVE-2026-98432）への対応を担当。公開サーバー12台の版を調べて影響を報告し、冗長構成を1台ずつ切り離して再起動することで、サービスを止めずに公開から5日以内に全台の更新を完了

書き方のコツはインフラエンジニアのスキルシートの書き方で詳しく解説しています。ほかの脆弱性への対応例はPHPの脆弱性「php2shell」の解説も参考にしてください。

対応の経験をスキルログで残す理由

脆弱性への対応は、何台を、どんな段取りで、何日で終えたかを書けると評価につながります。ExcelやWordで経歴を書き足していくと、案件ごとに書く項目がばらつき、台数や期間が抜けやすくなります。スキルログで記録すると、次の点で楽になります。

• 項目がそろう：案件ごとに期間・役割・プロジェクト規模・チーム規模・業種・担当工程・成果を同じ項目で入力するので、書き漏れがなく、案件どうしを比べやすい
• 体裁を整える手間がない：入力した内容はPDF出力で体裁の整ったスキルシートになり、新しい案件を足したらそのまま出し直せる
• 伸びたスキルが見える：スキルごとにS・A・Bなどの自己評価と経験年数を並べて確認でき、次に伸ばすところが分かる

インフラやセキュリティの運用経験が、求人や案件でどう評価されそうかを、転職・案件相談で一緒に確かめることもできます。

CVE-2026-98432は、IPv4のTCP接続を受け付ける処理の不具合で、外から接続を受け付けるLinuxサーバーが広く対象になります。RHEL・AlmaLinux・Debian・Amazon Linuxは修正済みのカーネルを公開しており、Ubuntuは修正版の準備中です。

まずは uname -r で動いているカーネルを確かめ、修正済みの版と比べましょう。対象であれば更新して再起動し、すぐに再起動できない場合は暫定対策を入れたうえで日程を決めておくことが大切です。

参考：Red Hat・CVE-2026-98432、Ubuntu・CVE-2026-98432、Debian セキュリティトラッカー、Amazon Linux セキュリティセンター、AlmaLinux公式ブログ、Anthropicの研究報告（英語）

カーネルを更新すれば再起動しなくても大丈夫ですか？

いいえ、再起動が必要です。新しいカーネルは再起動して初めて使われるため、更新しただけでは古いカーネルのまま動いています。

IPv6だけで通信していれば影響はありませんか？

主な問題はIPv4のTCPで起きます。ただし、多くのサーバーはIPv4も受け付けているため、IPv6を使っているからといって対象外とは判断せず、更新を進めましょう。

Dockerのコンテナのイメージを更新すれば防げますか？

防げません。コンテナはホストのカーネルを使っているため、更新が必要なのはホストのOSのカーネルです。

MPTCPを無効にすれば十分ですか？

十分ではありません。公開された攻撃の検証はMPTCPを使うサーバーが対象でしたが、Go公式もMPTCPに限らない問題の可能性があると説明しており、確実な対策はカーネルの更新です。

Ubuntuを使っている場合はどうすればよいですか？

修正版の公開を待ちながら、暫定対策を入れておきましょう。11月4日時点では準備中（pending）で、公開されたらaptで更新して再起動します。

ここまでの内容を踏まえて、まずは担当しているサーバーで uname -r を実行し、対応を終えたらその内容を記録しておきましょう。