LinuxのTCP脆弱性で認証不要root実行を実証｜MPTCP停止だけでは残る影響

LinuxのIPv4 TCP接続処理に、ネットワーク越しに認証なしで到達できる脆弱性CVE-2026-98432が10月15日に公表されました。Anthropicは10月27日、MPTCPリスナーを持つLinuxサーバーでroot権限のコマンド実行に至る実証を報告しました。Red Hatも10月30日、Criticalとして修正の提供を急ぐ方針を示しています。公開WebサーバーやAPI基盤を運用する担当者は、アプリの更新だけで済ませず、稼働中のカーネルと配布元の対応を確認してください。

優先する作業は、外部から到達するTCP待受を持つホストの特定、OS別の修正確認、更新後に修正済みカーネルで起動していることの確認です。MPTCPの無効化や通信フィルターは修正の代わりになりません。本稿は11月1日に一次資料を確認したニュース解説です。攻撃の再現試験は行っておらず、以下の点検手順は本サイトの提案を含みます。

通常のTCPへの影響とMPTCPでの実証を分ける

Linux CNAの公式CVEレコードは、TCP接続要求の並行処理で解放済みメモリーを参照するuse-after-freeを説明しています。問題の中心は、IPv4オプションを保持する領域を別の処理がまだ参照できる間に解放することです。HTTPの特定URLやログイン後の機能を使うことが前提ではなく、アプリが認証を判断するより前の接続処理に関係します。

Anthropicの研究報告では、MPTCPリスナーがあるサーバーへパケットを送り、認証情報も利用者の操作もなしにroot権限のコマンドを実行したとしています。報告上の所要時間は、カーネルのアドレスを得るまで48分、その後のコマンド実行まで約5分です。これは研究元の特定条件での結果であり、すべてのサーバーで同じ時間や成功率になるという測定値ではありません。

MPTCPは一つのTCP接続で複数の経路を利用する仕組みです。ただし、今回の不具合そのものがMPTCP専用という意味ではありません。Go Security Teamの注意喚起も、実証はMPTCPを必要とする一方、MPTCPリスナーがないシステムでも類似の攻撃を受ける可能性があると説明し、修正済みカーネルへの更新を推奨しています。

したがって「MPTCPを使うサービスを優先点検する」と「使っていないホストを対象外にする」は別の判断です。本サイトの提案は、公開TCPサービスを持つホスト全体を台帳に残し、実証条件に近い構成から先に対応することです。研究室での攻撃成功を実環境の侵害確認と同一視せず、侵害を断定するには別の調査根拠が必要です。

Red Hatの最新評価はCriticalと9.8

Red HatのCVEページは11月1日の確認時点で、重大度をCritical、CVSS 3.1を9.8としています。10月30日付のセキュリティ速報RHSB-2026-016も、認証不要のリモート攻撃者によるコード実行と、IPv4 TCP接続を受けるシステムへの広い影響を説明しています。古い報道やスキャン結果の評価だけで、サービス不能に限定された問題と判断しないでください。

同速報が直接の影響対象として挙げるのはRHEL 8・9・10とOpenShift Container Platformです。RHELカーネルに依存する製品でも、下層の更新を確認するよう求めています。受信TCPを持つWeb基盤では、サービス単位の評価に加えてホスト全体の更新を調整する必要があります。OS別の影響判定は、その配布元の現行資料に従います。

上流修正とOSの配信済みを区別する

公式CVEレコードは4.4での導入と、複数の安定版系列への修正を記載しています。上流の修正済み版には5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10が含まれます。ただし、これをOSパッケージの番号へそのまま当てはめないでください。配布元がバックポートする場合は、元の系列番号を保ったパッケージでも修正が入るためです。

配布元・対象	11月1日に確認した状態	判断時の注意
Debian 12 bookwormのlinux	securityの6.1.190-1でfixed	通常リポジトリー側の版と区別する
Debian 13 trixieのlinux	securityの6.12.113-1でfixed	source packageの表記。実行中のカーネルも確認する
Ubuntuのlinux	22.04・24.04・26.04・26.10はVulnerable／work in progress	予定番号を配信済みと読まない
RHEL 8・9・10	Red Hat速報は修正の提供を急ぐと説明	対象製品と利用する更新経路で最新状態を確認する

根拠はDebian Security TrackerとUbuntuのCVE追跡ページ、前述のRed Hat速報です。Ubuntuは10月30日更新の表示を確認しました。表は基本のlinuxパッケージについての抜粋で、HWE、AWS、Azure、GCPなどの別カーネルを一括判定するものではありません。Ubuntuの「work in progress in」に番号があっても、それだけで利用可能な修正版とは扱いません。

Goサービスでは待受の既定値も調べる

Goの公式GODEBUG資料によると、Go 1.24ではmultipathtcpの既定値が2となり、リスナー側でMPTCPを有効にする動作へ変わりました。アプリ担当者が明示的に導入した覚えがなくても、ビルドしたGoの版、互換性設定、実行環境の組み合わせを点検する理由があります。Goで書かれているという情報だけで、実際のソケットがMPTCPだと断定はできません。

Go Security TeamはGODEBUG=multipathtcp=0による実行時の既定動作変更と、メインモジュールのgo.modへgodebug multipathtcp=0を置く方法を案内しています。ただし、ソケット単位のSetMultipathTCPによる明示設定が優先されます。一つのサービスだけ変更しても他の待受が残り得るため、チーム自身がこの対策を脆い緩和策と位置付けています。

本サイトの提案は、バイナリーを作った担当者とホスト管理者で確認を分担することです。前者はGoの版、起動時の環境、明示的なソケット設定を調べます。後者はホストのカーネル、名前空間、公開範囲を確認します。設定変更を採用しても、カーネル修正の対応票は閉じず、暫定対策と恒久対応を別々に記録してください。

最初の確認は稼働版と待受から始める

自社管理ホストでの読み取り用の確認例は次のとおりです。出力には待受アドレスやプロセス情報が含まれる場合があるため、共有時は公開範囲に注意します。これらは脆弱性を攻撃して確かめるコマンドではありません。

uname -r
cat /etc/os-release
sysctl net.mptcp.enabled
ss -ltn
ss -Mltn

uname -rは実際に動いているカーネルを確認するために使います。パッケージを導入しただけで再起動していない状態と区別します。sysctlの1はMPTCPを利用できる設定であり、全リスナーが使っている証拠ではありません。0でも通常TCP側の不具合は解消しません。ssの表示や対応オプションは環境で異なるため、コマンドが失敗したりMPTCP行が見えなかったりしても、それだけで安全と判定しないでください。

次に、外部公開アドレス、ロードバランサーの転送先、管理用の接続先、同じノード上の別サービスを対応付けます。仮想マシンはそのゲスト、コンテナー基盤は実際にカーネルを提供するホストを確認対象にします。アプリのイメージを更新した記録と、ノードのカーネルを修正した記録を混ぜないことが大切です。管理サービスでは提供元の責任範囲も確認します。

暫定フィルターはIPオプションとTCPオプションを混同しない

Red HatはIPv4のIPオプションを含むTCPパケットを落とすnftablesの例を公開しています。TCPヘッダー内の通常のTCPオプションとは対象が異なります。速報は、露出を減らす対策で完全な防御にはならず、必要な通信を妨げる可能性があるとしています。カーネル修正までの暫定措置として、適用前に自社構成と照合してください。

またCIQのRocky Linux向け検証資料は、MPTCPを無効にした状態でも通常TCPの対象経路が残ることを確認しています。同資料の検証範囲は列挙されたホスト環境に限定され、コンテナーや転送通信のすべてを実証したものではありません。他社の検証を、自社の全経路で同じ効果が得られる保証へ置き換えないでください。

本サイトでは、既存ルールの保管、帯域外の管理経路、戻す担当者と手順を用意してから、一台の検証環境へ適用する進め方を提案します。ルールの適用位置と管理方式は、既存のファイアウォール構成に合わせて設計します。公式例を使う場合も、ルールの存在、対象チェーン、カウンター、必要な業務通信の疎通を確認し、設定ファイルを保存しただけで有効と判断しないようにします。

更新後は再起動と配布元の根拠をそろえる

修正済みパッケージが利用できる場合は、通常の更新経路で導入し、必要な再起動を計画します。冗長化しているWeb基盤なら一台ずつ切り離し、再起動後に稼働版、ヘルスチェック、実際のHTTP・API通信を確認して戻す方法が考えられます。これは構成に応じた運用提案で、無停止を保証する手順ではありません。

完了記録には、ホスト、OS系列、利用するカーネルパッケージ、配布元が示す修正根拠、再起動後のuname -r、確認日時を残します。更新後に異常があれば、新旧の起動版と通信制限の変更を分けて切り分けます。復旧のため古いカーネルへ戻す場合は未修正状態への復帰を認識し、露出の制限と再対応期限を設定してください。

今回の要点は、MPTCPでのroot実行実証を重く見ながら、通常TCPを調査対象から外さないことです。修正の有無は上流の番号だけで決めず、OSの系列と実行中のカーネルで確認します。暫定対策が動いていても修正対応を終えず、配信・導入・起動の三段階がそろったことを完了条件にしてください。

関連記事

既報のPHP重大脆弱性と侵害後のカーネル確認で扱ったCVE-2026-46300とは別件です。本稿はIPv4 TCPの接続処理へネットワーク越しに到達するCVE-2026-98432を対象とし、同じ「カーネル更新」でも対応済みと取り違えないようにしてください。