Xray緊急セキュリティアップデート：LinuxでCVE-2026-98432を修正する方法

重要なポイント（Key Takeaways）

• CVE-2026-98432はLinuxカーネルの脆弱性です。 アプリケーションのアップデートによって攻撃リスクを軽減できますが、根本的な解決にはOSのセキュリティパッチが必要です。
• Anthropicは、MPTCPリスナーを公開しているサーバーに対して、リモートからroot権限でコマンドを実行できることを実証しました。 ただし、すべてのLinux環境で同じ条件の攻撃が成立することを意味するものではありません。
• Xray-core v26.10.31では、MPTCPがデフォルトで無効化されました。 公式リリースでは、v26.10.29の公開取り消しも確認されています。
• Go 1.24では、対応するLinuxシステムにおいてMPTCPリスナーがデフォルトで有効になる動作が導入されました。 実際の挙動はビルド設定、アプリケーションの構成、カーネルの対応状況によって異なります。
• MPTCPの無効化は暫定的な緩和策です。 完全な修正には、ディストリビューションのベンダーが確認したカーネル修正を適用し、実行中のシステムで有効になっていることを確認する必要があります。

最終更新日：2026年11月1日。 Xrayの緊急リリースでは 、XrayのアップグレードとLinuxの更新の両方が明確に推奨されています。これらは別々のメンテナンス作業として実施する必要があります。

CVE-2026-98432とは？

CVE-2026-98432は、LinuxカーネルのIPv4 TCP接続処理に存在するUse-After-Free（解放済みメモリの使用、UAF）の脆弱性です。

特定のタイミング条件下で、一方の処理経路が接続オプション用のメモリを解放した後、別の処理経路がそのメモリにアクセスしてしまう可能性があります。

問題の原因となるカーネルの変更はLinux 4.4までさかのぼります。ただし、これは不具合の起源を示すものであり、その後のすべてのカーネルがセキュリティ更新後も脆弱であることを意味するわけではありません。

脆弱性の深刻度については、Linuxディストリビューションのベンダーによって評価が異なります。

これらの評価は、Ubuntuの脆弱性トラッカー 、Amazon Linuxの脆弱性トラッカー 、Red Hatのセキュリティ情報で確認できます 。

したがって、単一のCVSSスコアをすべてのベンダーで共通する評価として扱うべきではありません。

Linuxカーネルの脆弱性はどのように発生するのか？

この問題は、TCP接続の確立処理におけるIPv4オプションデータの所有権とメモリのライフサイクル管理に関係しています。

1. 接続確立待ちのリクエストがIPv4オプションデータを保持します。
2. カーネルはそのオプションを複製せず、新しく作成されたソケットへ移します。
3. 別のCPUが、再送された接続要求への応答を同時に準備する可能性があります。
4. 新しいソケットが先に破棄された場合、応答処理が解放済みメモリにアクセスする可能性があります。

修正では、関連する処理経路で即時のメモリ解放を行う代わりに、kfree_rcu()を使用します。

これにより、既存のRCUリーダーによるアクセスが完了するまでメモリの回収を遅延させ、並行処理中の不正なメモリアクセスを防ぎます。

LinuxカーネルのCVEアナウンスでは 、関連するリクエスト移行処理の問題についても説明されています。

運用上、重要な点があります。アプリケーションレベルの認証に、この脆弱性への防御を依存することはできません。

問題はカーネルがTCP接続を確立する段階で発生する可能性があります。HTTPのログインページなどの認証処理は、その後の段階で実行されるためです。

Anthropicは実際に何を実証したのか？

Anthropicは、2026年10月27日に公開した研究レポートで 、未公開の社内研究モデルがMPTCPリスナーを公開しているLinuxサーバーに対するExploitを生成したことを説明しています。

報告された攻撃チェーンでは、最初にカーネルアドレスを漏えいさせてアドレス空間配置のランダム化を回避し、その後、攻撃者が指定したコマンドをroot権限で実行することに成功しました。

攻撃時間については、慎重に解釈する必要があります。

これらはPoCの実行時間であり、Claudeが脆弱性を発見したり、Exploitを開発したりするまでに必要だった時間ではありません。

また、任意のLinuxサーバーを侵害するために必要な一般的な時間を示すものでもありません。

Anthropicによると、競合状態を利用する攻撃が失敗した場合でも、TCPハンドシェイクが失敗するだけでシステムがクラッシュしないケースがあり、攻撃者は繰り返し試行できます。

この研究は重大な攻撃可能性を実証していますが、それだけで実環境における大規模な攻撃の発生を証明するものではありません。

なぜGo 1.24によってMPTCPが注目されたのか？

MPTCP（Multipath TCP）は、1つのTCP接続で複数のネットワーク経路を利用できる技術です。

通常のTCPを使用するクライアントからの接続を受け付ける場合でも、アプリケーションはMPTCPリスナーの作成を要求できます。

Goの公式GODEBUGドキュメントでは 、次の設定が説明されています。

Go 1.24では、multipathtcp=2がデフォルト設定として導入されました。

ただし、Goの互換性設定は、モジュールやワークスペースで指定されたGoのバージョン、明示的なビルド指示などにも影響されます。

コンパイラーのバージョンだけでは、実際に有効なMPTCP設定を判断できません。

さらに、GoのネットワークAPIでは 、SetMultipathTCPを使用して個別のリスナーのデフォルト設定を上書きできます。

また、MPTCPが利用できない場合やクライアントが対応していない場合には、通常のTCPにフォールバックすることも説明されています。

したがって、通常のTCP通信だけが観測されていても、サーバー側でMPTCPが無効化されている証拠にはなりません。

Xray-core v26.10.31では何が変更されたのか？

Xray PR #7291では 、リスナーのデフォルト設定が変更されました。

主要な処理は次のとおりです。

lc.SetMultipathTCP(false)

if sockopt != nil {
    lc.SetMultipathTCP(sockopt.TcpMptcp)
}

これは関連する処理を抜粋したものであり、リスナー実装全体を示すコードではありません。

この変更により、MPTCPはデフォルトで無効になります。ただし、明示的な設定が存在する場合は引き続き有効化できます。

そのため、管理者はアップグレード後も既存のtcpMptcp設定を確認する必要があります。

管理パネル経由でXrayを導入している場合は、パネルが実際に起動しているXrayの実行ファイルを確認してください。

管理パネルの更新が成功しても、同梱されているXray-coreが置き換えられたことや、実行中のプロセスが再起動されたことを意味するわけではありません。

優先的に確認すべき環境は？

外部からアクセス可能なサービスと、実行中のカーネルの修正状況に基づいて優先順位を決めることが推奨されます。

MPTCPプロジェクトのアプリケーション一覧には 、Caddy v2.10.0やTraefik v2.11.26、v3.4.2など、特定のバージョンからデフォルトでMPTCPが有効になることが記載されています。

これらは調査対象を特定するための参考情報であり、個々の環境で脆弱性が悪用可能であることを直接示すものではありません。

Xrayのリリース情報では、SocksやHTTPのインバウンドサービスをLANに公開しているAndroidクライアントについても注意喚起されています。

クライアントアプリケーションであっても、インバウンドリスナーを作成することで攻撃対象になる可能性があります。

Goセキュリティチームのアドバイザリでは 、根本的なカーネルの問題はMPTCP固有のものではないと説明されています。

MPTCPリスナーが存在しないシステムでも、別の悪用経路によって影響を受ける可能性がある点に注意が必要です。

修正済みのLinuxカーネルバージョンは？

継続的に更新されているLinuxカーネルのCVE記録には 、以下の上流カーネルの修正済みバージョンが記載されています。

最初のアナウンスでは、メインラインカーネルの修正が7.3-rc7に含まれていることも示されています。

本番環境では、利用しているLinuxディストリビューションの公式サポート対象の更新チャネルを使用してください。

上流カーネルのバージョン番号だけで脆弱性の有無を判断することはできません。

ディストリビューションによっては、古いベースバージョンを維持しながら修正をバックポートしている場合があります。

確認されたベンダー情報による状況は次のとおりです。

Debianのセキュリティトラッカーに記載されているのはソースパッケージのバージョンであり 、uname -rの出力と必ずしも一致しません。

AlmaLinuxのパッチに関する発表では 、テストビルドと本番向けリリースが明確に区別されています。

パッケージの状況は、この記事の更新日以降に変更される可能性があります。

ステップ1：実行中のシステムを確認する

対象となるLinuxホストで、次の読み取り専用コマンドを実行します。

uname -r
cat /etc/os-release
sysctl net.mptcp.enabled
sysctl net.ipv4.tcp_migrate_req

Xrayの実行ファイルがコマンド検索パスに含まれている場合は、次のコマンドでバージョンを確認できます。

xray version

結果を解釈する際には、次の点に注意してください。

• uname -rは現在実行中のカーネルを表示します。ディスク上にインストールされているすべてのカーネルを示すものではありません。
• net.mptcp.enabled=1はMPTCPソケットの作成が許可されていることを示しますが、実際にリスナーが存在する証拠にはなりません。
• net.mptcp.enabled=0であっても、カーネルの脆弱性が修正済みであるとは限りません。
• MPTCPのsysctl項目が存在しない場合、機能が利用できないか、実行環境が制限されている可能性があります。これだけでCVEの影響がないと判断することはできません。
• tcp_migrate_req=0でも、再送された接続要求に関連する別の処理経路の問題は解消されません。

LinuxカーネルのMPTCPドキュメントによると 、net.mptcp.enabledはネットワーク名前空間ごとに設定される項目です。

そのため、ホストのネットワーク名前空間だけを確認しても、すべてのコンテナの設定を把握したことにはなりません。

ディストリビューション、カーネルパッケージ、実行中のカーネル、サービスの実行ファイル、外部からアクセス可能なインターフェースをまとめて記録することが推奨されます。

これにより、修正後の再確認を再現可能な形で実施できます。

ステップ2：必要に応じてMPTCPの公開リスクを軽減する

業務でMPTCPが不要な場合は、現在のネットワーク名前空間で新しいMPTCPソケットが作成されないよう、一時的に無効化できます。

sudo sysctl -w net.mptcp.enabled=0

このコマンドは実行時の設定を変更します。

再起動後も維持する必要がある場合は、システムの標準的な設定管理方法で永続化してください。

この設定はソケットの作成を制御するためのものです。そのため、値を変更しただけで既存のリスナーが置き換わったと考えてはいけません。

計画的なメンテナンス時間内にサービスを再起動し、その後の設定を確認してください。

別のネットワーク名前空間についても同様の確認が必要です。

Goサービスの場合、実際にプロセスを管理しているサービスマネージャーで環境変数を設定します。

無関係なSSHセッションでexportを実行しても、すでに動作しているデーモンには反映されません。

例えば、systemdを利用している場合は、example.serviceを実際のサービス名に置き換えて次のコマンドを実行します。

sudo systemctl edit example.service

以下の設定を追加します。

[Service]
Environment="GODEBUG=multipathtcp=0"

既存のGODEBUGに必要な設定が含まれている場合は、それらを保持し、カンマ区切りの値のうちMPTCPに関連する項目だけを変更してください。

その後、計画したメンテナンス時間内に設定を再読み込みし、サービスを再起動します。

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl is-active example.service

サービスの再起動に成功したことは、サービスが利用可能であることを示すだけであり、脆弱性が完全に修正されたことを証明するものではありません。

アプリケーションがSetMultipathTCP(true)を明示的に呼び出している場合、この環境変数によるデフォルト設定は上書きされます。

また、継承されたリスナーや外部で管理されるリスナーについても個別の調査が必要です。

Goセキュリティチームは、プログラムごとにMPTCPを無効化する方法は見落としが発生しやすいと指摘しています。

外部に公開されたリスナーを1つでも見落とせば、実証された攻撃条件が残る可能性があります。

この緩和策を適用した場合でも、カーネルの更新を必ず実施してください。

ステップ3：Xrayを更新し、カーネル修正を有効化する

既存のパッケージ管理、コンテナ管理、または管理パネルの更新手順を使用して、Xrayをv26.10.31、もしくは同等の緩和策を維持している後続バージョンへアップグレードします。

続いて、利用しているLinuxディストリビューションのCVEアドバイザリで指定されたカーネルパッケージをインストールします。

一般的なパッケージ更新を実行しただけでは、修正が完了した証拠にはなりません。

修正済みパッケージがまだ提供されていない場合、更新が保留されている場合、または異なるカーネル系列のパッケージをインストールした場合には、対策が不十分になる可能性があります。

推奨される確認手順は次のとおりです。

1. パッケージのセキュリティアドバイザリがCVE-2026-98432を明確に対象としていることを確認します。
2. パッケージがホストのアーキテクチャとカーネル系列に一致することを確認します。
3. リモートサーバーを再起動する前に、コンソールへのアクセス手段とロールバック方法を準備します。
4. ベンダーがサポートする手順で修正済みカーネルを有効化します。
5. 実行中のカーネルとアプリケーションの正常性を再確認します。

通常のカーネル更新と再起動を実施した後、次のコマンドを実行します。

uname -r

結果を、インストール済みパッケージおよびベンダーのアドバイザリと照合してください。

修正済みカーネルがディスク上に存在するだけでは、そのカーネルが実際に起動されているとは限りません。

Livepatchを使用している環境では、適用済みのライブパッチが実行中のカーネルに対するCVE-2026-98432の修正を含んでいることを明確に確認する必要があります。

Livepatchエージェントがインストールされていることや、有効なサブスクリプションが存在することだけでは不十分です。

ファイアウォールルールで時間を稼ぐことはできるか？

Red Hatは、IPv4オプションを含むTCPパケットをフィルタリングする暫定的なnftables対策を公開しています。

ただし、Red Hatのセキュリティ情報では 、このフィルタリングが業務に影響する可能性があり、パッチ適用の代わりにはならないと警告しています。

IPv4オプションとTCPオプションは、異なるプロトコルフィールドです。

IPv4ヘッダーのオプションを対象とするルールを、TCPオプションを無差別に遮断するルールに置き換えてはいけません。

ベンダーが提供するルールを適用する前に、パケットがどの経路を通過するかを確認してください。

例えば、ホストのINPUTチェーンとコンテナへの転送経路は同じではありません。

実際のルーティング、ファイアウォール管理ツール、ロールバック手順に照らしてルールを検証する必要があります。

フィルタリングはあくまで一時的なリスク軽減策として扱い、管理責任者と解除計画を明確にしてください。

よくある質問と危険な誤解

XrayをアップグレードすればCVE-2026-98432は完全に修正されますか？

いいえ。Xrayの更新によって変更されるのは、アプリケーションのリスナー動作です。Linuxカーネルにも有効な修正が必要であり、MPTCPを明示的に有効化している設定も確認する必要があります。

MPTCP接続が見つからなければ安全ですか？

いいえ。待機中のリスナーには確立済み接続が存在しない場合があります。また、接続状況のスナップショットからカーネルの修正状況を判断することはできません。

IPv6専用サービスは影響を受けませんか？

カーネルのアナウンスによると、IPv4の主要な所有権管理の問題は、オプションが複製される対応するIPv6処理経路には影響しません。

ただし、CALIPSOに関連するIPv6のリクエスト移行処理について、別の問題も報告されています。

結論を出す前に、デュアルスタックリスナーを含め、実際にIPv4経由でアクセスできるかを確認してください。

HTTPSやアプリケーションのログイン認証でサーバーを保護できますか？

これらの制御はTCP接続の確立後に機能します。

したがって、カーネルの接続処理に存在する今回の脆弱性に対する緩和策として扱うべきではありません。

Dockerイメージを再ビルドすれば修正できますか？

いいえ。アプリケーションイメージを再ビルドしても、コンテナが使用するLinuxカーネルは置き換わりません。

修正対象には、基盤となるホストまたは仮想マシンを含める必要があります。

Anthropicの研究は、すべてのLinuxサーバーでroot権限を奪取できることを証明していますか？

いいえ。公開されたExploitはMPTCPリスナーを使用しています。

脆弱性の潜在的な影響範囲と、実際に攻撃が成功した条件は区別して考える必要があります。

パッチを適用すれば、過去にサーバーが侵害されていなかったことも証明できますか？

いいえ。脆弱性の修正とインシデント調査は異なる問題です。

不審な活動が確認された場合は、関連する証拠を保存し、組織のインシデント対応手順に従って調査してください。

まとめ（Conclusion）

CVE-2026-98432への対応には、アプリケーションとオペレーティングシステムの両方を対象としたセキュリティメンテナンスが必要です。

Xrayの緊急アップデートは、デフォルトのMPTCP公開リスクを軽減します。しかし、恒久的な修正には、実行中のLinuxカーネルに適切なセキュリティパッチを適用する必要があります。

まず、インターネットに公開されているサーバーから調査を開始してください。カーネルとリスナーの状態を確認し、必要な暫定対策を適用したうえで、ベンダーが確認したパッチをインストールし、有効化されていることを検証しましょう。

単に修正済みパッケージをダウンロードまたはインストールしただけでは対応完了とはいえません。現在稼働しているシステムに修正が適用されていることを確認してから、セキュリティ対応を完了としてください。