Linuxカーネルの深刻度9.8の欠陥――AIが実証した攻撃の条件と、ディストリビューションごとの修⁠正⁠状⁠況

LinuxカーネルのIPv4のTCP処理にある欠陥（CVE-2026-98432）について、Anthropicは、2026年10月27日に、認証なしで、遠隔からroot権限でコマンドを実行する攻撃を、実証したと発表しました（Anthropic）。深刻度は、カーネルのCVE発行元の評価で、9.8（最高10）です（CVEレコー⁠ド⁠）⁠。

「認証なしでroot」という見出しは、事実です。ただし、実証には、条件があります。この記事は、その条件と、自分のサーバーが対象かどうかの確認方法、ディストリビューションごとの修正状況を、一次情報で整理したものです。情報は、2026年10月30日の時点のもの⁠で⁠す⁠。

日本語で出回っている情報には、原文と異なる訳や要約が、かなり見受けられます。この記事は、一次情報を私たちも原文で確認して書いていますが、読者の皆さんも、各社の原文でのご確認をお勧めします。出典は、各記述のそばに示してい⁠ま⁠す⁠。

要点

• 欠陥は、TCPの接続を確立する途中で、IPv4のオプションの領域が、まだ使われているのに解放される、競合状態です。解放されたメモリを使う「use-after-free」になり、接続の確立の段階で、認証の前に、遠隔から到達できます（CVEレコー⁠ド⁠）⁠。
• 影響を受けるのは、カーネル4.4以降です。上流の修正版は、5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3です（CVEレコー⁠ド⁠）⁠。
• Anthropicの実証は、MPTCP（複数の経路を使うTCPの拡張）の待ち受けを持つサーバーが対象で、研究用の、非公開のモデルが作った攻撃コードによるものです。KASLR（カーネルの配置の乱数化）の突破に48分、そのあと、約5分で、コマンドの実行に至ったとしています（Anthropi⁠c⁠）⁠。
• ただし、欠陥そのものは、MPTCP専用ではありません。Goのセキュリティチームも、MPTCPの待ち受けがなくても、似た攻撃を受けうる、と書いています（oss-securit⁠y⁠）⁠。
• 実際の攻撃（悪用）の報告は、確認できていません。CISAの「悪用が確認された脆弱性（KEV）」には、10月29日のデータの時点で、登録がありません（CISAのKEVのデータを、私が直接確⁠認⁠）⁠。
• ディストリビューションの修正は、まちまちです。Debianは修正済み、Ubuntuは、全リリースで作業中、Amazon Linux 2は修正待ち⁠で⁠す⁠。

何が起⁠き⁠た⁠か

欠陥が入ったのは、SYNを受けた接続の要求を、ハッシュ表に入れる変更（コミット079096f103fa）で、カーネル4.4からです（CVEレコー⁠ド⁠）⁠。

欠陥の⁠仕⁠組⁠み

CVEの説明では、仕組みは次のとおりです（CVEレコー⁠ド⁠）⁠。

1. 接続の要求（SYN）に、IPv4のオプション（Record Route、Timestamp）が付いていると、カーネルは、それを保⁠存⁠す⁠る
2. 接続が成立すると、そのオプションは、コピーされずに、新しい接続の側へ渡⁠さ⁠れ⁠る
3. 同じ接続について、再送されたSYNが、別のCPUで処理されると、そのCPUは、オプションを読み⁠続⁠け⁠る
4. その間に、接続が閉じて、オプションが、単純なkfree()で解放されると、解放後のメモリを使うこと⁠に⁠な⁠る

修正は、解放を、他のCPUが読み終わるのを待ってから行うkfree_rcu()に、変えるものです。IPv6は、最初の問題の対象外です。移行の処理の同じ問題は、別のパッチで直すとされています（CVEレコー⁠ド⁠）⁠。

起こりうることとして、CVEの説明は、カーネルのメモリの内容の漏えい、範囲外への書き込み、制御の乗っ取り、クラッシュを挙げてい⁠ま⁠す⁠。

実証は、何を示し⁠た⁠の⁠か

Anthropicの記事には、5つの実証があり、Linuxはその一つです（ほかは、Chrome、Safari、Android、Windows）。Linuxの部分で述べられていることは、次のとおりです（Anthropi⁠c⁠）⁠。

• 研究用の、公開されていない社内のモデル（「unreleased, internal research model」）が、攻撃コードを⁠書⁠い⁠た
• 対象は、MPTCPの待ち受けを持つ、Linuxのサーバー。認証も、利用者の操作も、要⁠ら⁠な⁠い
• 第一段階で、競合を使って、カーネルのメモリを多めに読み出し、返信にカーネルのポインタが入るまで続けて、KASLRを破る（4⁠8⁠分⁠）
• 第二段階で、コールバックのポインタを書き換え、あらかじめカーネルのメモリに置いたコードを実行させ、rootでコマンドを実行する（約⁠5⁠分⁠）
• 競合に負けても、ハンドシェイクが失敗するだけで、システムは落ちないため、やり⁠直⁠せ⁠る

Anthropicは、これを「実証」として示しています。実際に、誰かが攻撃を受けた、という報告では、ありません。記事全体の注記として、これらの攻撃の連鎖には、人間による最初の指示があったことも、書かれてい⁠ま⁠す⁠。

この記事には、攻撃コードを公開したのか、伏せているのかが、書かれていません（私が読んだ範囲）。Goチームのoss-securityへの投稿は、「Anthropicが説明したエクスプロイト」と書くだけで、コードは含まれていません（oss-security）。公開の有無は、確認できていま⁠せ⁠ん⁠。

「認証なしでroot」は、どこまで⁠本⁠当⁠か

報道の見出しと、一次情報のずれの読み方は、PHP2Shellの記事にも書きま⁠し⁠た⁠。

Red Hatは、起こりうることを「クラッシュ（DoS）、または、メモリの破壊の可能性」と書いていて、緩和策は「ない」としています（Red Ha⁠t⁠）⁠。

評価の差は、攻撃の複雑さ（AC）を、低とするか、高とするかの違いです。各社が、その理由を、詳しく書いているかは、私が読んだページでは確認できていません。Anthropicは、競合に負けても、やり直せる、としています。どちらの評価でも、優先して直す対象⁠で⁠す⁠。

MPTCPが、なぜ⁠重⁠要⁠か

MPTCPは、一つの通信を、複数の経路に分けて使える、TCPの拡張です。Anthropicの実証は、MPTCPの待ち受けが前提で⁠し⁠た⁠。

気づきにくいのは、Goです。Go 1.24以降で作られたプログラムは、Linuxで、待ち受けの接続を、既定でMPTCPにします（Goのセキュリティチームの説明。oss-security）。Goで書かれたWebサーバー、リバースプロキシ、APIゲートウェイなどが、自覚のないままMPTCPの待ち受けになっている可能性があり⁠ま⁠す⁠。

Goチームがoss-securityに書いた回避策は、次のとおりです（oss-securit⁠y⁠）⁠。

• 実行時に、環境変数GODEBUG=multipathtcp=0を設⁠定⁠す⁠る
• ビルド時に、go.modへgodebug multipathtcp=0を書く
• ソケットごとに、SetMultipathTCPで指⁠定⁠す⁠る

Goチーム自身が、この方法を「もろい」としています。「MPTCPの待ち受けを一つでも公開したままにすると、システムは脆弱なまま」だからです。Goの既定の動作を変えることは、今は時期尚早としています（oss-securit⁠y⁠）⁠。

ディストリビューションごとの修⁠正⁠状⁠況

2026年10月30日に、各社のページで確認した状況⁠で⁠す⁠。

「上流のカーネルは直っているのに、自分のサーバーは直らない」状態が、Ubuntuなどで、実際に起きています。Anthropicの記事の、サポート中の安定版のすべてに取り込まれた、という記述は、上流のカーネルの話です。ディストリビューションが、自社のカーネルに取り込むのは、別の段階です。同じ週のGitLabの欠陥でも、「直ったはずなのに、直っていない」ことが、実際に起きま⁠し⁠た⁠。

ディストリビューションのカーネルは、上流とは違う番号で、修正を取り込むことがあります。番号だけで、修正済みかどうかを決めず、各社の告知で、確認してくだ⁠さ⁠い⁠。

いま、や⁠る⁠こ⁠と

1. 自社のサーバーの、カーネルと、修正状況を確⁠認⁠す⁠る

uname -r

この番号を、上の表の各社のページと照らします。インターネットに公開しているサーバーから、先に確認してくだ⁠さ⁠い⁠。

2. MPTCPの待ち受けがあるか、確⁠認⁠す⁠る

sysctl net.mptcp.enabled
ss -Mltn

ss -Mltnで、MPTCPの待ち受けが表示されれば、実証の条件に当たります（この確認方法は、KrakenDの記事に基づいています。公式の案内では、ありません）。コンテナは、ホストのカーネルを使うため、コンテナのイメージを更新しても、直りません。ホストのカーネルを更新し⁠ま⁠す⁠。

3. 修正版があれば、更新して、再起⁠動⁠す⁠る

カーネルは、更新しただけでは、古いカーネルが動き続けます。再起動する（ライブパッチを使っている場合は、その適用を確認する）必要があり⁠ま⁠す⁠。

4. 更新できないときの、つなぎ⁠の⁠対⁠処

安全にはなりません。時間稼ぎ⁠で⁠す⁠。

• MPTCPを止める（カーネルの設定net.mptcp.enabled=0。Goのプログラムには、GODEBUG=multipathtcp=0）。実証の前提は、なくなりますが、欠陥は、残⁠り⁠ま⁠す
• 公開しているサーバーは、受け付ける通信を、必要最小限⁠に⁠絞⁠る

Red Hatは、緩和策はない、としています（Red Ha⁠t⁠）⁠。

5. 侵害⁠の⁠確⁠認

悪用の報告は、確認できていませんが、公開情報は、そろっています。次の点を、確認してくだ⁠さ⁠い⁠。

• カーネルが、突然、クラッシュや再起動をしていないか。CVEの説明は、メモリの破壊による、カーネルの異常停止を、起こりうることとして挙げて⁠い⁠ま⁠す
• ただし、Anthropicの説明では、競合に負けても、システムは落ちません。痕跡が残らないこともあ⁠り⁠ま⁠す
• 公開のサーバーに、見覚えのないプロセス、ユーザー、外向きの通信が⁠な⁠い⁠か

やってはいけな⁠い⁠こ⁠と

• 「MPTCPを使っていないから大丈夫」と、決めない。欠陥は、MPTCP専用ではあり⁠ま⁠せ⁠ん
• 上流のカーネルが直ったことで、安心しない。自分のディストリビューションの修正が、出ているかどう⁠か⁠で⁠す
• 更新して、再起動せずに、済ま⁠せ⁠な⁠い
• ネットで見つけた攻撃コードを、本番で試⁠さ⁠な⁠い

未確⁠認⁠の⁠点

• 実際の攻撃（悪用）の報告は、確認できていません。CISAのKEVにも、登録はあり⁠ま⁠せ⁠ん
• Anthropicの攻撃コードが公開されているか。Anthropicの記事は、触れていません。Goチームの投稿は、「Anthropicが説明した」と書くだけで、コードは添えてい⁠ま⁠せ⁠ん
• MPTCPの待ち受けがない環境で、遠隔からのコード実行が可能か。実証は、ありません。可能性は、否定もされてい⁠ま⁠せ⁠ん
• カーネルの設定で、MPTCPが既定で有効かどうかは、ディストリビューションと設定によります。私は、各社の既定を、確認してい⁠ま⁠せ⁠ん
• Red Hatの、RHELの版ごとの修正状況は、確認できてい⁠ま⁠せ⁠ん
• CVEの説明は、きっかけを、IPv4オプション（Record RouteやTimestamp）付きのSYNとしています。この種の通信を境界で落とす対処が効くかは、公式に示されておらず、私も確認してい⁠ま⁠せ⁠ん
• 10月28日にKEVへ入った、LinuxカーネルのCVE-2026-46300は、別の欠陥です。PHP2Shellとの連鎖の経緯は、エンジニア向けのまとめにあ⁠り⁠ま⁠す

関⁠連⁠記⁠事

• PHPの更新がまだの人へ――PHP2Shellの現状と、いま確認すること：PHP2Shellの現状。ファイアウォールの侵害では、PHPに加えて、カーネルの欠陥も使われ⁠ま⁠し⁠た
• PHPの重大な脆弱性「php2shell」（CVE-2026-109618／109619）エンジニア向けまとめ【随時更新】：PHP2Shellと、Linuxカーネルの欠陥（CVE-2026-46300）の連鎖の、技術的⁠な⁠経⁠緯
• PHP2Shellの報道と、一次情報で、合っていなかった点：見出しの数字が、一次情報とどう違ったか。数字の⁠読⁠み⁠方
• GitLabの深刻な欠陥は、2件ある――10月12日の修正版では足りない理由と、確認すること：同じ週の、GitLabの深刻度10.0の欠陥。GitLab本体だけを上げても、直らない場合があ⁠り⁠ま⁠す
• 不正アクセスが相次ぐ今、経営者が先に決めておくこと――ゼロトラストとAI時代のセキュリティ対策：不正アクセスが相次ぐ今の、経営者向けの考え方。AI時代のセキュリテ⁠ィ⁠対⁠策
• Jenkins本体の脆弱性15件――認証なしは1件、でも「読み取り権限」だけで届くものがある：同じ週に、Anthropic OSS programが、報告者に並んだ件。Jenkins本体の脆弱性⁠1⁠5⁠件

自社のサーバーの、カーネルの確認や、更新、侵害の確認でお困りの方は、お問い合わせくだ⁠さ⁠い⁠。