はじめに
CVE-2026-98432 は、Linux カーネルの IPv4 TCP の接続確立処理に存在する use-after-free（UAF）の脆弱性です。2026 年 10 月 15 日に Linux カーネルの CVE チームが公開し、10 月 27 日には Anthropic が、MPTCP（Multipath TCP）のリスナーを持つサーバーに対して、ネットワーク経由で root 権限のコマンド実行に成功したと発表しました。
この発表で注目が集まった一方、「すべての Linux サーバーで root を取られるのか」「MPTCP を使っていなければ関係ないのか」といった判断に迷う声も多く見られます。また、upstream では修正済みでも、ディストリビューションごとに修正パッケージの提供状況が大きく異なります。
- CVE-2026-98432 の仕組みと、評価主体ごとの CVSS の違い
- Anthropic の root RCE 実証と、CVE として公表された不具合の違い
- Ubuntu、RHEL、Debian、SUSE、Amazon Linux、Oracle Linux の修正状況
- 自社環境の影響と修正適用状況を確認する読み取り専用の手順
- 修正版が未提供の場合に優先すべき暫定対応と、残るリスク
結論として、root 権限の奪取が実証されたのは特定の構成であり、一般の Linux 環境で同じ攻撃が必ず成立するとは限りません。ただし、脆弱性そのものは IPv4 TCP の処理にあるため、MPTCP を使っていないことだけを理由に影響なしと判断せず、配布元の修正カーネルを適用する前提で対応を進める必要があります。2026 年 10 月 30 日時点で、Debian、SUSE の一部、Amazon Linux 2023 の一部、Oracle Linux の UEK は修正済み、Ubuntu と RHEL は修正パッケージが未提供です。
CVE-2026-98432 とは
CVE-2026-98432 は、IPv4 TCP の接続確立時に、すでに解放されたメモリを別の CPU が参照してしまう不具合です。Linux 4.4 で入り込み、2026 年 10 月に upstream で修正されました。CVE のタイトルは修正内容をそのまま表しています。
参考: Linux カーネル CVE アナウンス（CVE-2026-98432）
“ipv4: free inet_opt and ireq_opt after an RCU grace period”
（ipv4: inet_opt と ireq_opt を RCU の猶予期間の後に解放する。）
https://lists.openwall.net/linux-cve-announce/2026/10/15/1
| 項目 | 内容 |
|---|---|
| 対象 | Linux カーネルの IPv4 TCP（接続確立処理、リクエストソケットの移行処理） |
| 脆弱性の種類 | 競合状態に起因する use-after-free（UAF） |
| 混入 | Linux 4.4（コミット 079096f103fa） |
| upstream の修正版 | 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3 |
| CVE 公開日 | 2026 年 10 月 15 日（Linux カーネル CVE チーム） |
| IPv6 | 主要な問題の影響を受けない（移行処理に関する IPv6 の問題は別途対応予定） |
CVSS は評価主体によって異なる
CVSS 3.1 の評価は、Linux カーネル CNA の 9.8 と各ディストリビューションの 8.1 に分かれています。主な違いは、競合に勝つ難しさを攻撃複雑性（AC）でどう評価するかです。数値の違いは誤記ではなく、評価主体の判断と対象製品の違いによるものです。
| 評価主体 | CVSS 3.1 | 攻撃複雑性 | 備考 |
|---|---|---|---|
| Linux カーネル CNA | 9.8 | Low | 10 月 24 日にスコアを追加。Ubuntu も 9.8 を表示 |
| Red Hat | 8.1 | High | 暫定値と表記。評価が更新されている |
| SUSE | 8.1 | High | 深刻度 Important |
| Oracle Linux | 8.1 | High | 暫定値と表記。深刻度 Important |
| Amazon Linux | 8.1 | High | 評価が更新されている |
（2026 年 10 月 30 日時点。各社の CVE ページで最新値を確認してください。）
どのような攻撃が成立するのか
まず脆弱性の仕組みを平易に説明し、次に Anthropic の実証内容と、各ベンダーが評価している影響を分けて整理します。
平易な説明: 片付けたメモリを別の処理が使ってしまう
TCP の接続確立中、カーネルは接続要求ごとに小さな管理データ（リクエストソケット）を作り、接続が完了すると正式なソケット（子ソケット）へ情報を引き継ぎます。このとき、IPv4 のオプション情報がコピーされずに引き継がれていました。そのため、子ソケットが破棄されてオプション情報のメモリが解放された直後に、別の CPU が再送された接続要求の応答を作るためにまだ同じメモリを読んでいる、という状況が起こり得ます。
技術的な詳細
CVE アナウンスによると、tcp_v4_syn_recv_sock() がリクエストソケットのオプション（ireq->ireq_opt）を、コピーせずに子ソケット（newinet->inet_opt）へ移します。リクエストソケットはリスナーのロックを取らずに処理されるため、別の CPU が同じリクエストソケットに対する再送 SYN を処理し、tcp_check_req() から SYN-ACK を送ることがあります。このとき tcp_v4_send_synack() などは RCU の読み取りロックだけでオプションを参照しますが、子ソケットの破棄時に inet_sock_destruct() が通常の kfree() で解放するため、ip_options_build() で UAF が発生します。
リクエストソケットの移行処理でも、複製されたソケットが同じオプションのポインターを共有するため、同様の問題があります。修正では、inet_sock_destruct() と tcp_v4_reqsk_destructor() で kfree_rcu() を使い、読み取り中の CPU がいなくなる RCU の猶予期間の後にメモリを解放するよう変更されました。IPv6 については、Red Hat が次のように説明しています。
参考: Red Hat（CVE-2026-98432）
“IPv6 is not affected by the primary issue because tcp_v6_syn_recv_sock() duplicates the options.”
（tcp_v6_syn_recv_sock() はオプションを複製するため、IPv6 は主要な問題の影響を受けない。）
https://access.redhat.com/security/cve/cve-2026-98432
Anthropic が実証した攻撃構成
Anthropic は 2026 年 10 月 27 日、未公開の社内研究モデルを使い、この脆弱性を悪用して MPTCP リスナーを持つ Linux サーバー上で、認証やユーザー操作なしに root 権限でコマンドを実行する攻撃を実証したと発表しました。研究全体と、ほかの 4 つの事例は『Claude による脆弱性発見｜Chrome・Linux など 5 事例と防御策』で解説しています。
Anthropic によると、攻撃は 2 段階です。1 段階目で競合を利用してカーネルのメモリを読み出し、KASLR をリモートから回避します。2 段階目で同じ UAF を使ってコールバックポインターを書き換え、制御フローを乗っ取ります。PoC では、カーネルポインターの漏えいに 48 分、コマンド実行までにさらに 5 分を要しました。成功するまで試行を繰り返せる理由について、Anthropic は次のように説明しています。
参考: Anthropic（Discovering and exploiting vulnerabilities in critical, real-world software with Claude）
“a lost race only fails the handshake without crashing the whole system”
（競合に負けてもハンドシェイクが失敗するだけで、システム全体はクラッシュしない。）
https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
実証、ベンダー評価、悪用状況を分けて考える
この脆弱性については、情報の種類によって示している影響が異なります。混同しないよう、次のように整理できます。
| 区分 | 内容 |
|---|---|
| CVE として公表された不具合 | IPv4 TCP の接続確立処理とリクエストソケットの移行処理における UAF |
| Anthropic の実証 | MPTCP リスナーを持つサーバーで、ネットワーク経由の root 権限コマンド実行に成功（検証したカーネルのバージョンや構成は非公開） |
| ベンダーの評価 | Red Hat は、最も起こりやすい結果をカーネルクラッシュによる DoS とし、メモリ破損は理論上の可能性と説明 |
| 実際の悪用 | 2026 年 10 月 29 日時点の報道では悪用の報告はなく、CISA KEV にも未登録 |
| 公開情報では判断できないこと | MPTCP リスナーがないサーバーで同じように root 権限を奪取できるか、実証環境以外のカーネルで同じ手法が成立するか |
MPTCP を使用していなければ安全なのか
安全とは言い切れません。CVE の対象は IPv4 TCP の処理であり、Red Hat も、公開された TCP サービスに到達できる攻撃者が特殊なタイミングのリクエストでこの競合を悪用し得ると説明しています。MPTCP は Anthropic が root 権限の奪取まで実証した構成の前提ですが、脆弱性の前提ではありません。
一方で、MPTCP リスナーを持つ公開サーバーは、実際に攻撃が実証された条件と一致するため、修正の優先度を上げる判断材料になります。MPTCP はアプリケーションが明示的に要求したときに使われる仕組みで、カーネルで機能が有効になっていても、MPTCP で待ち受けているとは限りません。
| 確認できた状態 | 読み取れること | 読み取れないこと |
|---|---|---|
MPTCP の機能が有効（net.mptcp.enabled = 1） | アプリケーションが MPTCP ソケットを作成できる | 実際に MPTCP で待ち受けているか |
| MPTCP のリスナーが存在する | Anthropic の実証と同じ種類の待ち受けがある | 外部から到達できるか |
| 外部から MPTCP リスナーに到達できる | 実証された攻撃構成と一致し、優先度が高い | 自社のカーネルで同じ攻撃が成立するか |
| MPTCP を使っていない | 実証された攻撃構成とは一致しない | CVE の影響がないこと（IPv4 TCP の不具合は残る） |
Linux ディストリビューション別の影響と修正状況
upstream で修正されていても、ディストリビューションの修正パッケージが提供されているとは限りません。逆に、古いバージョン番号のカーネルでも修正がバックポートされている場合があります。2026 年 10 月 30 日（日本時間）に各社の CVE ページで確認した内容を、まず OS 別の概要で示し、続いて系列別の修正パッケージを掲載します。
| OS | 修正パッケージの提供状況 | 判断のポイント |
|---|---|---|
| Ubuntu | 未提供（22.04 以降の多くは修正作業中） | 16.04 / 18.04 / 20.04 は Vulnerable。ページは 10 月 29 日更新 |
| RHEL | 未提供（RHEL 8 / 9 / 10 は Fix deferred） | Real Time と OpenShift 4 の RHCOS も対象。RHEL 7 は影響なし |
| Debian | 提供済み | bookworm は linux と linux-6.12 で修正版が異なる |
| SUSE | 一部提供済み | SLES 15 SP7 と SUSE Linux Micro 6.0 / 6.1 は未提供 |
| Amazon Linux | 一部提供済み | AL2023 の kernel6.12 / kernel6.18 のみ修正済み |
| Oracle Linux | UEK は提供済み | RHCK は errata の記載なし |
系列別の修正パッケージとアドバイザリ
修正済みの系列がある Debian、SUSE、Amazon Linux、Oracle Linux は、同じ OS でも系列やパッケージによって状況が異なります。利用中の系列の行で判断してください。
Debian
| リリース | パッケージ | 修正版・アドバイザリ |
|---|---|---|
| Debian 12（bookworm） | linux | 6.1.190-1（DLA-4841-1） |
| Debian 12（bookworm） | linux-6.12 | 6.12.113-1~deb12u1（DLA-4850-1） |
| Debian 13（trixie） | linux | 6.12.113-1（DSA-6568-1） |
SUSE
| 製品 | 状況 | 修正版（kernel-default） |
|---|---|---|
| SLES 16.0 | 修正済み | 6.12.0-160000.40.1 以降 |
| SLES 15 SP4 LTSS | 修正済み | 5.14.21-150400.24.246.1 以降 |
| SLES 15 SP5 LTSS | 修正済み | 5.14.21-150500.55.195.1 以降 |
| SLES 15 SP6 LTSS | 修正済み | 6.4.0-150600.23.143.1 以降 |
| SLES 15 SP7、SUSE Linux Micro 6.0 / 6.1 | Affected（未提供） | なし |
修正済みの製品は、アドバイザリ SUSE-SU-2026:24386-1 と SUSE-SU-2026:24422-1 で提供されています。
Amazon Linux
| リリース | パッケージ | 状況・アドバイザリ |
|---|---|---|
| Amazon Linux 2023 | kernel6.18 | Fixed（10 月 24 日、ALAS2023-2026-3251） |
| Amazon Linux 2023 | kernel6.12 | Fixed（10 月 29 日、ALAS2023-2026-3335） |
| Amazon Linux 2023 | kernel（6.1） | Pending Fix |
| Amazon Linux 2 | kernel（Core、5.4 / 5.10 / 5.15 Extras） | Pending Fix |
Oracle Linux
| リリース | カーネル | 修正版・アドバイザリ |
|---|---|---|
| Oracle Linux 7 / 8 | UEK R6（kernel-uek） | 5.4.17-2136.360.3.1（ELSA-2026-500397） |
| Oracle Linux 8 / 9 | UEK 5.15 系（kernel-uek） | 5.15.0-325.221.6 系（ELSA-2026-500398） |
| Oracle Linux 9 / 10 | UEK 6.12 系（kernel-uek） | 6.12.0-207.111.5.4 系（ELSA-2026-500399） |
| Oracle Linux（全般） | RHCK（kernel） | errata の記載なし。UEK の状況を当てはめず個別に確認 |
RHEL の「Fix deferred」は、将来の更新で修正される可能性を示す表記ですが、修正の提供や時期を保証するものではありません。Red Hat は、同社の基準（導入の容易さ、幅広い環境への適用性、安定性）を満たす緩和策はないとしています。SUSE や Amazon Linux の「Affected」「Pending Fix」も、製品やパッケージごとに状況が異なるため、一律に「未修正」と読み替えず、利用中の系列の行を確認してください。
Amazon Linux 2023 は、同じ OS でも kernel（6.1）、kernel6.12、kernel6.18 で修正状況が異なります。Oracle Linux も UEK と RHCK で状況が異なるため、OS の名前だけでなく、実際に起動しているカーネルパッケージの系列で判断しましょう。
自社環境への影響を確認する方法
確認は、OS とカーネルの特定、配布元の修正版との照合、MPTCP と外部到達性の確認の順に進めます。紹介するコマンドはいずれも読み取り専用で、設定変更やサービス停止は伴いません。
一般ユーザーで実行できます。NAME と VERSION_ID を見て、前章の表のどの行に当たるかを特定します。
cat /etc/os-release一般ユーザーで実行できます。表示されるのは現在起動しているカーネルです。この値を upstream の修正版（6.1.190 など）と比べるだけでは、バックポートの有無が分からないため判定できません。
uname -r一般ユーザーで実行できます。Ubuntu / Debian 系は次のコマンドで、状態が ii のカーネルイメージのバージョンを確認します。
dpkg -l 'linux-image*'RHEL / Oracle Linux / Amazon Linux 系は、利用しているカーネルパッケージ名を指定します。Oracle Linux の UEK は kernel-uek、Amazon Linux 2023 は kernel（6.1）、kernel6.12、kernel6.18 の 3 系列があります（AWS の AL2023 カーネル更新ガイド）。
rpm -q kernel kernel-uek kernel6.12 kernel6.18導入されていないパッケージは「is not installed」と表示されるため、該当するパッケージの行だけを確認します。新しいカーネルが導入済みでも、手順 2 の結果と一致しなければ、まだ再起動されていません。
手順 3 のバージョンを、前章の表に掲載した各社の CVE ページやアドバイザリの修正版と比較します。Ubuntu Pro Client を導入している環境では、変更を加えずに影響を確認する dry run を利用できます。公式ドキュメントの例と同様に sudo を付けて実行します。
sudo pro fix --dry-run CVE-2026-98432RHEL / Oracle Linux 系では、Red Hat のドキュメントにある次のコマンドで、適用済みのセキュリティアドバイザリを一覧できます。Oracle Linux では、出力に ELSA-2026-500397 / 500398 / 500399 のうち該当するものが含まれているかを確認します。
dnf updateinfo list security --installedアドバイザリが一覧にない場合も、修正版が未提供の可能性と、未適用の可能性の両方があります。必ず配布元の CVE ページの状況とあわせて判断します。
いずれも一般ユーザーで実行でき、値を表示するだけで変更は伴いません。net.mptcp.enabled は MPTCP ソケットの作成可否（既定値 1）、net.ipv4.tcp_migrate_req は CVE アナウンスで同様の問題があるとされたリクエストソケット移行の有効・無効（既定値 0）を示します。
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req次に、MPTCP で待ち受けているソケットの有無を確認します。-M は MPTCP ソケット、-l は待ち受け中のソケット、-n は数値表示を指定します。古いカーネルや iproute2 では MPTCP のリスナーが表示されない場合があるため、結果が空でもアプリケーションの設定とあわせて判断します。
ss -Mln脆弱性は IPv4 TCP の接続確立処理にあるため、IPv4 で待ち受けている TCP ポートを確認します。一般ユーザーで実行できます。Local Address が 0.0.0.0 やグローバル IP アドレスのものは、外部から到達できる可能性があります。
ss -4tlnサーバー上の待ち受けだけでは、実際に外部から接続できるかは分かりません。ファイアウォール、クラウドのセキュリティグループ、ロードバランサーの設定を確認し、どの送信元から到達できるかを把握します。
手順 4 で配布元の修正版が適用済み、かつ手順 2 のカーネルが修正版であれば、対応は完了しています。修正版が提供済みで未適用なら次章の更新へ、修正版が未提供なら「修正版がない場合の暫定対応」へ進みます。MPTCP の有無や到達性は、更新の優先順位を決める材料であり、影響の有無を決める材料ではありません。
更新方法と修正後の確認
恒久的な対応は、配布元が提供する修正版カーネルの適用です。カーネルは更新パッケージを導入しただけでは反映されず、再起動が必要です。
各ディストリビューションの通常の更新手順で、修正版カーネルを導入します。RHEL / Oracle Linux 系では、Red Hat のドキュメントに記載された dnf update --advisory=アドバイザリ ID で特定のアドバイザリだけを適用することもできます。Amazon Linux 2023 で kernel（6.1）を利用していて修正を早く適用したい場合は、修正済みの kernel6.12 / kernel6.18 への切り替えも選択肢ですが、カーネル系列の変更になるため、AWS のガイドに沿って互換性を検証してから実施してください。
メンテナンス時間を確保して再起動します。Ubuntu では /var/run/reboot-required が再起動待ちの目印になりますが、Livepatch の設定によってはこの通知が消されることがあるため、ファイルの有無だけで判断しないでください。Livepatch や Ksplice などのライブパッチで反映する場合は、この CVE が対象に含まれていることを配布元の情報で確認したうえで利用します。
再起動後に uname -r を実行し、導入した修正版のカーネルで起動していることを確認します。ブートローダーの既定設定によっては、古いカーネルで起動する場合があります。
主要サービスの起動状態、待ち受けポート、監視の正常性、外部からの疎通を確認します。あわせて、対象ホスト、更新前後のカーネル、適用したアドバイザリ、作業日時を記録しておくと、監査や次回の脆弱性対応で役立ちます。
クラウド VM、コンテナホスト、Kubernetes ノードの注意点
- コンテナはホストのカーネルを共有するため、更新すべきはコンテナイメージではなく、コンテナを動かしているホストのカーネルです。
- マネージド Kubernetes のノードは、ノードイメージの更新とノードの入れ替えでカーネルが変わる場合があります。どの単位でカーネルが管理されているかを、利用中のサービスの情報で確認します。
- オートスケールなどで新しいインスタンスを起動する構成では、起動に使うイメージ自体が修正版カーネルを含んでいるかも確認します。
修正版がない場合の暫定対応
Ubuntu や RHEL のように修正版が未提供の場合、Red Hat は同社の基準を満たす緩和策はないとしており、ベンダーが有効性を示した回避策は確認できていません。以下は、一般的な攻撃面の縮小策と、脆弱な処理の一部を使わないようにする設定であり、CVE-2026-98432 の確実な回避策ではありません。
| 対応 | 軽減されること | 残るリスク |
|---|---|---|
| 公開 TCP ポートの送信元を必要な範囲に制限する | 外部の不特定の攻撃者からの到達 | 許可した送信元や内部ネットワークからの攻撃 |
| 不要なリスナー・サービスを停止する | 攻撃の入り口となるポートの数 | 業務上必要なポートを経由した攻撃 |
MPTCP が業務で不要なら利用をやめる（net.mptcp.enabled を 0 にする） | Anthropic が root 権限の奪取を実証した構成との一致 | IPv4 TCP の不具合そのもの。効果はベンダーから示されていない |
net.ipv4.tcp_migrate_req を既定値の 0 のまま維持する | CVE アナウンスで同様の問題があるとされた移行処理の利用 | 接続確立時の主要な競合状態 |
| カーネルの異常終了や予期しない再起動を監視する | DoS やクラッシュの兆候の早期検知 | 攻撃の防止にはならない |
| 配布元の CVE ページとアドバイザリを追跡する | 修正版公開後の適用までの時間 | 修正版公開までの期間のリスク |
sysctl の変更は通信やアプリケーションの動作に影響する可能性があるため、MPTCP を利用しているアプリケーションがないことを確認し、検証環境で影響を確かめてから本番へ反映することを推奨します。優先順位としては、外部から到達できるサーバー、とくに MPTCP リスナーを公開しているサーバーから対応を進めると効果的です。
暫定対応はあくまで修正版が出るまでのつなぎです。修正版が公開されたら、暫定対応の有無にかかわらず、修正カーネルの適用と再起動を計画しましょう。
まとめ
CVE-2026-98432 は IPv4 TCP の接続確立処理にある UAF で、Anthropic が root 権限の奪取を実証したのは MPTCP リスナーを持つ特定の構成です。影響判定には実証条件ではなく、OS、カーネルパッケージ、配布元の修正状況の確認が欠かせません。
- CVE の対象は IPv4 TCP の処理で、MPTCP 専用の脆弱性ではない
- root 権限の奪取は特定構成での実証で、悪用の報告はまだない
- CVSS は評価主体によって 8.1〜9.8 と幅がある
- Debian や Oracle Linux の UEK などは修正済み、Ubuntu と RHEL は未提供
- uname -r の値だけで修正済み・未修正を判定しないようにします。
- 修正版を導入したら、再起動と実行中カーネルの再確認まで行います。
- 修正版がない間は、到達性の制限と MPTCP の利用確認から進めます。
以上、最後までお読みいただきありがとうございました。
