CVE-2026-98432：UbuntuとRHELには依然としてパッチがなく、Claudeモデルはすでにエクスプロイトを作成済み

CVE-2026-98432 に関するこの2つの事実は、どうにも噛み合わない。1つ目は、Linux カーネルの IPv4 TCP ハンドシェイクにおける use-after-free であり、ログインも操作も不要でネットワーク経由で到達可能なうえ、カーネル CVE チームはこれを 9.8 と採点した。2026年10月30日時点で、Ubuntu は 22.04、24.04、26.04、26.10 向けの修正版を一切リリースしておらず、Red Hat は RHEL 8、9、10 を影響対象として挙げているものの、修正も承認済みの緩和策も示していない。2つ目の事実は、10月27日に Anthropic が公表した研究で、未リリースの Claude モデルが、MPTCP リスナーを稼働させたサーバーに対して未認証でのリモート root 取得を可能にする実証コードを作り出したというものだ。カーネルアドレスの漏洩まで約48分、そこからコマンド実行までさらに5分ほどだった。

最大手エンタープライズLinuxベンダー2社がまだ修正できない脆弱性に、一部を機械が書いた実用的なエクスプロイトが存在する――これはよくある月例パッチ日ではない。これは、カーネルアップグレードプロセスとエージェントアクセスポリシーが互いに関係するかどうかを決める事例だ。

バグを1段落で

TCP接続の確立時、受信パケットに付随するIPオプションはコピーされるのではなく、新しいソケットに引き渡されます。ハンドシェイクが再送されると、そのパケットはオプションバッファを所有するCPUとは別のCPUで処理される可能性があり、その2番目のCPUは1番目のCPUがすでに解放したメモリを読み取ることがあります。リクエスト移行経路にも同様の競合が存在します。影響を受ける範囲はカーネル4.4から始まり、つまり、保守されているカーネルをまだ実行しているほとんどのマシンが該当します。上流の修正であるコミット code>e3f33b0a1d89/code> は、他のコアがもはや参照を保持できなくなるまで、オプションバッファの解放を遅らせます。

悪用可能性はその仕組みから導かれる。認証不要、ユーザー操作不要、ネットワークから到達可能な経路、そして再試行できる競合状態である。PoCが実用的である理由についてのAnthropic自身の要約は、まさにその性質だ。競合に敗れてもマシンがクラッシュするのではなく1回のハンドシェイクが失敗するだけなので、攻撃者は再び試みる。

ベンダー3社、深刻度番号3つ

スコアリングの内訳こそが、身につける価値のある部分です。なぜなら、それが今週あなたのスキャナーがチケットを起票するかどうかを決めるからです。

• カーネルCVEチーム — 9.8、クリティカル。ネットワークから到達可能、権限不要、操作不要。

• Red Hat — 8.1、重要。同社の見解では、実際にこのレースに勝つことは難しい。

• Ubuntu — 優先度が高いが、確認したページには数値スコアが公開されていません。

9.8と8.1の差は、バグに関する見解の相違ではなく、レースに勝てる確率に関する見解の相違だ。どちらも正当化できる立場であり、その違いは運用上重要な意味を持つ。公開PoCを伴う9.8は緊急事態であり、困難なレースを伴う8.1は計画的な修正案件だ。実機での再現数値を誰かが公表するまでは、最前線のモデルが実際にこのレースを勝ち取ったと報じられている以上、このレースは勝ち取り可能と読むのが誠実な解釈だ。

誰に修正策があり、誰にないのか

10月29～30日時点では、安定したカーネルならパッチ適用済みだと考えている人々を引っかける形で、状況は一様ではない。

• Debian 12 bookworm — 6.1.190-1 で DLA-4841-1 により修正済み。

• Debian 13 trixie — 6.12.113-1 にて DSA-6568-1 により修正済み。

• Ubuntu 22.04, 24.04, 26.04, 26.10 — リリース済みの修正はなく、作業中です。

• Ubuntu 16.04、18.04、20.04 — 脆弱性あり、修正は未リリース。

• RHEL 8、9、10 および OpenShift 4 — 影響あり、修正なし、Red Hat が承認した緩和策なし。

• RHEL 6 および 7 — 影響を受けません。

• Amazon Linux 2023 — カーネル 6.18 は修正済みと報告されています； Oracle Linux UEK は修正済みと報告されています； SUSE は、一部のリリースは修正済み、その他はまだテスト中であると報告していますが、バージョン名は明示していません。

修正を含むアップストリームの安定版リリースは 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 および 7.3 です。ディストリビューションのパッケージを使わずにカーネルを自分でコンパイルする場合は、この一覧を自身のビルドと照らし合わせて確認してください。

なぜMPTCPは繰り返し話題になるのか

このバグはMPTCP固有ではなく、多くの報道がここで誤っている。Red Hatは、到達可能なあらゆるTCPサービスをトリガーになり得るものとして扱う。MPTCPが提供するのは実証済みの経路であり、トラフィックを供給しているのはGoだ。バージョン1.24以降では、カーネルでMPTCPが有効になっていれば、Linuxのリスニングソケットに対してデフォルトでマルチパスTCPを有効にする。Goのセキュリティチームは10月29日にこの組み合わせについて警告した。

つまり「MPTCP を無効化する」ことは、Anthropic が実証した経路を取り除くだけで、脆弱性そのものを取り除くわけではありません。これは、ある特定の注意点を伴う、正当化可能な暫定措置です。今日の Go サービスにおいて実施する価値はありますが、パッチ適用済みカーネルの代わりにはなりません。

チェックは短時間で済みます：

• code>ss -Mltnp/code> — 現在 MPTCP を使用しているソケットを一覧表示します。

• code>net.mptcp.enabled/code> — カーネル機能がそもそも有効になっているかどうか。

• code>net.ipv4.tcp_migrate_req/code> — デフォルトではオフです。オンにした場合は、もう一度オフにしてください。

特に Go の場合、code>GODEBUG=multipathtcp=0/code> を実行時に指定するか、code>godebug/code> 行を code>go.mod/code> に記述すると、そのバイナリをオプトアウトできます。

これらのいずれもベンダー公認ではありません。Red Hatは自社基準を満たす緩和策がないと明言しており、その一文は希望的観測に基づく回避策の一覧よりも有用です。

Anthropicが実際に公開したもの

この研究は限定的かつ具体的なものだ。未公開のClaudeモデルは、CVEとMPTCPリスナーを持つターゲットを与えられると、約48分でカーネルアドレスを漏えいさせる一連の攻撃チェーンを構築し、その約5分後にコマンド実行に到達した。Anthropicはそのエクスプロイトを公開しておらず、10月29日時点では、ベンダーもCVEレコードも実環境での攻撃を報告していなかった。この脆弱性はCISAのKEVカタログには含まれていない。10月30日、第三者のGitHubリポジトリがレース誘発およびメモリリークの実験用ツールを公開した。これは再現ハーネスであり、完全なコード実行には至らない。

その組み合わせこそが興味深い点だ。能力は実証され、兵器は伏せられており、そして実現を可能にする詳細——脆いレースを信頼できるものに変えるリトライ特性——が文章として公開されている。そのレースを再現できる者なら誰でも、なぜそれを粘り強く続ける価値があるのかを今や知っている。

今週やること

• 修正プログラムが存在する場合はパッチを適用して再起動してください。カーネルの修正プログラムは、インストールされても再起動されていなければ修正ではありません。次のコマンドで確認してください: code>uname -r/code>.

• お使いのディストリビューションにパッチが存在しない場合 — Ubuntu 22.04～26.10、RHEL 8～10 — 今すぐ決断してください。ベンダーのライブパッチを適用するのか、修正済みのバージョンへ移行するのか、それともGoサービスでMPTCPを無効にしたうえでリスクを許容するのか。

• MPTCP の露出をオフだと仮定せず、棚卸しする。デフォルトはあなたの設定ではなく Go で変更されており、デフォルトの変更は設定差分には現れない。

• 再起動を事前にリハーサルする。この種の修正には完全な再起動が必要であり、最も多くの時間を失うのは、メンテナンス時間帯にフェイルオーバー対応を初めて確認することになる組織だ。

このCVEが実際に提起する2つの問い

第一はエクスプロイト生成に関するもので、哲学的ではない。あるモデルは、特定の有効化構成を持つターゲット上で、非常に多くの人間の研究者が見つけられなかったシーケンスを1時間以内に発見した。エクスプロイトが公開されるかどうかに関わらず、タイムラインは変わった。公開アドバイザリから実際に動作するエクスプロイトまでの時間枠は、今やそのアドバイザリを読むモデルを基準に測られている。

第二に、ベンダーがパッチを当てられないときにパッチ適用が何を意味するかだ。カーネルを同梱して提供するディストリビューションと、修正を含むカーネルは同じオブジェクトではなく、その間の隔たりこそ、この記事の読者の大半にとってこの脆弱性が存在するまさにその場所である。OrcaRouter AI Incident Archive は、こうしたインシデントを一次情報源、重大度、信頼度に照らして索引化しており、ニュースサイクルが過ぎた後に残す価値があるのはこの話のこの版だ。

やってはいけないのは、これを「ベンダー待ち」として片付けることだ。ベンダー自身のページには、まだ待つものは何もないと書かれている。

出典に関する注記: 仕組み、カーネル4.4以降の影響範囲、アップストリームのコミット code>e3f33b0a1d89/code>、安定版のリストならびに緩和策のガイダンスは、CVEレコードと、2026年10月30日に読んだ各ディストリビューションのアドバイザリに基づく。9.8、8.1およびUbuntuのHighという評価は、それぞれカーネルCVEチーム、Red Hat、Canonicalによるものである。ディストリビューションごとのパッチ状況は、DebianのDLA-4841-1およびDSA-6568-1、Red HatとUbuntuのCVEページ、ならびに同日のベンダーによる声明に基づく。概念実証のタイムライン、48分と5分という数値、および再試行の特性は、Anthropicによる10月27日の研究によるもので、同研究はエクスプロイトを公開しなかった。10月30日のラボリポジトリは第三者によるものとされており、当社のものではない。