Claude が見つけた Linux の脆弱性 CVE-2026-98432｜深刻度 9.8 の出どころと更新の確認

「Claude が Linux に深刻度 9.8 の脆弱性を見つけた」の中身

2026 年 10 月 27 日、Anthropic は研究記事「Discovering and exploiting vulnerabilities in critical, real-world software with Claude」を公開しました。公開されていない社内の研究モデルでブラウザーと OS の重大な脆弱性を見つけ、攻撃の連鎖を 5 件実演した内容です。このうち Linux の件が、深刻度 9.8 で、認証なしに root の権限を奪える脆弱性として注目されています。

まず確認してほしいのは、自社のサーバーの Linux カーネルが修正済みかどうかです。そのうえで、AI が脆弱性の発見から攻撃コードの作成までを担ったことを、開発と運用の前提にどう反映するかを考えてください。

本記事は、Anthropic の研究ページ、CVE.org の CVE 記録、NVD のページ、Ubuntu・Debian・Red Hat のセキュリティ情報、Go の開発チームの告知を、2026 年 10 月 31 日に確認した内容に基づきます。同じ Frontier Red Team の別の研究は AI の自己複製は起きたのか で、PHP の重大な脆弱性への対応は php2shell (CVE-2026-109618) 対応 で扱っています。

結論：まず自社の Linux の修正状況を確認する

結論は 4 点です。

• Linux の脆弱性は CVE-2026-98432 です。CVE 記録では 4.4 以降のカーネルが影響を受け、保守中の各 stable ブランチで修正済みです
• 深刻度 9.8 は、CVE を登録した Linux カーネルの CNA が付けた CVSS 3.1 の値です。Red Hat は 8.1 と評価しており、Anthropic の研究ページには CVSS の記載がありません
• 2026 年 10 月 31 日の確認では、ディストリビューションと版によって修正の提供状況が違います。更新の要否は、自分の版の状態で決めます
• Claude は脆弱性の発見と攻撃コードの作成を担い、人はプロンプトの用意、スキャンの基盤の構築、ベンダーへの報告を担いました

FIXIT

9.8 って、Anthropic が付けた点数なの？

Dodai

違います。CVE を登録した Linux カーネル側の評価です。Anthropic の研究ページに点数はありません。

FIXIT

じゃあ、まず何を見ればいい？

Dodai

使っているディストリビューションのセキュリティ情報で、その版が修正済みかを見てください。次の章から順に整理します。

Anthropic の研究は何を示したのか

研究を担ったのは Anthropic の Frontier Red Team です。使ったのは公開されていない社内の研究モデルで、モデル名の記載はありません。見つけた脆弱性は、Anthropic の協調的な脆弱性開示のポリシーに沿ってベンダーに報告されています。ポリシーでは、開発者に 90 日の修正期間を設け、公開アドバイザリより詳しい内容を Anthropic が話すまでに、さらに 45 日を置くとしています。

研究ページが挙げる 5 件の攻撃の連鎖は、次のとおりです。

研究ページによると、Chrome の 62 件はすべて critical か high の評価で、サンドボックスの脱出 13 件とレンダラーの侵害 21 件を含みます。個別の CVE 番号は、研究ページに載っていません。Safari と Android も、研究ページに CVE 番号の記載はありません。

Linux の脆弱性 CVE-2026-98432 の中身

実演の条件：MPTCP のリスナーを持つ Linux サーバー

Anthropic の説明では、遠隔の攻撃者が、MPTCP (マルチパス TCP) のリスナーを持つ Linux サーバーにパケットを送ると、認証もユーザーの操作も無しに、root として任意のコマンドを実行できます。原因は、競合状態によって起きる use-after-free で、攻撃は 2 段階です。1 段階目で KASLR (カーネルのアドレス配置のランダム化) を遠隔から破り、2 段階目で攻撃者の選んだシェルコマンドを root で実行します。

攻撃が競合に負けても、TCP の接続の確立が失敗するだけで、システム全体は止まりません。そのため攻撃者は、成功するまで何度でも試せると研究ページは説明しています。

CVE 記録が示す原因と影響を受ける版

CVE 記録は、Linux カーネルの CNA が 2026 年 10 月 15 日に公開しました。題は「ipv4: free inet_opt and ireq_opt after an RCU grace period」です。IPv4 の TCP で、SYN を受けた段階の IP オプションが子ソケットに引き継がれたあと、別の CPU が再送された SYN に応答している間に子ソケットが解放されると、ip_options_build() で use-after-free が起きます。修正は、この解放を RCU による遅延解放に切り替える内容です。

CVE 記録では、カーネル 4.4 で入った変更 (commit 079096f103fa) 以降が影響を受けます。修正が入った upstream の版は次のとおりです。

ディストリビューションのカーネルは、独自の版番号で修正を取り込みます。たとえば Ubuntu 24.04 LTS のカーネルは 6.8 系で、上の表にはありません。自分のカーネルが修正済みかは、表の版と比べるのではなく、ディストリビューションのセキュリティ情報で判断します。

深刻度 9.8 の出どころ

9.8 (Critical) は、CVE 記録で Linux カーネルの CNA が付けた CVSS 3.1 の基本値です。ネットワーク越しに攻撃でき、攻撃の難しさは低く、権限もユーザーの操作も要らず、機密性・完全性・可用性のすべてに大きな影響が出る、という評価です。

ほかの機関の評価は、次のとおり分かれています。

研究ページにある評価は Chrome の件の「critical か high」だけで、CVSS の値はどの件にも載っていません。9.8 を「Anthropic の評価」と読むのは誤りです。

MPTCP を使っていないサーバーも対象外とは言えない

Anthropic の実演は MPTCP のリスナーを持つサーバーが対象ですが、CVE 記録は IPv4 の TCP の処理の不具合として説明しており、MPTCP には触れていません。

Go の開発チームは 2026 年 10 月 29 日の告知で、根本のバグは MPTCP に固有ではなく、MPTCP のリスナーが無いシステムも似た攻撃を受ける可能性があると書いています。あわせて、Go 1.24 以降で作ったプログラムは、Linux で待ち受けるソケットの MPTCP を既定で有効にすると説明しています。

更新が要る環境の確認

2026 年 10 月 31 日に確認した、主なディストリビューションの状態は次のとおりです。

Ubuntu では、linux-aws、linux-azure、linux-gcp、linux-oracle などの派生カーネルにも、Vulnerable や work in progress のものがあります。各ページは更新されるため、最新の状態は各ディストリビューションのページで確認してください。上の 3 つ以外のディストリビューションは、今回確認していません。

確認の手順は、次の 4 つです。ここからは、公式の記載を作業に読み替えた編集部の整理です。

1. 使っているディストリビューションとカーネルの版を確認する。起動しているカーネルの版は、下の uname -r で分かる
2. ディストリビューションのセキュリティ情報で CVE-2026-98432 を検索し、自分の版の状態を見る
3. 修正版が出ている版は、パッケージを更新して再起動する。カーネルの更新は、通常は再起動のあとに有効になる
4. 修正版がまだ出ていない版は、ディストリビューションの案内を確認する。Red Hat は、緩和策は無いか、あっても基準を満たさないとしている

uname -r

Go の開発チームは、Go のプログラムの MPTCP を GODEBUG=multipathtcp=0 などで無効にする方法を示しています。ただし Go の開発チームは、この方法を壊れやすい緩和策としています。MPTCP のリスナーが 1 つでも残ればシステムは脆弱なままで、攻撃がすべて MPTCP に依存するという前提にも立っているためです。カーネルの更新の代わりにはなりません。

クラウド上のインスタンスは、利用者が更新できるカーネルと、事業者が管理するカーネルがあります。コンテナはホストのカーネルを共有するため、ホスト側の更新が要ります。システムの保守を外部に預けている場合は、保守先に次の 3 点を聞いてください。

• 対象のサーバーのディストリビューションと版
• CVE-2026-98432 の修正の適用状況と、再起動の予定
• 修正版が未提供の版を使っている場合の方針

FIXIT

うちのサーバー、MPTCP なんて使ってるか分からないよ。

Dodai

使っていないからと更新を見送ると事故ります。Go の開発チームも、MPTCP 固有のバグではないと告知しています。

FIXIT

古い版は、どうすればいいの？

Dodai

修正版がまだ無い版は、まずディストリビューションの案内を確認してください。更新の時期は、その案内で決めます。

Claude は何をして、人は何をしたのか

研究ページでは、5 件の節のそれぞれで、最初のプロンプトのあとに Claude が脆弱性を見つけ、攻撃コードを書いたと説明されています。Windows の件では、Anthropic が実行ファイルを Claude に渡し、ソフトウェアの動作をリバースエンジニアリングさせました。Claude は注釈付きの再現コードを書き、そのあとで脆弱性を探しています。確認済みの発見には、Claude が自動で亜種の分析も行いました。

研究ページから読み取れる人の作業は、次のとおりです。

• プロンプトの用意
• 並列にスキャンのエージェントを回す基盤の構築
• ベンダーへの報告

研究ページによると、見つかった問題はすべて、標準化した検証とリスクの格付けの工程を通っています。この工程を誰がどう担ったかは、研究ページにありません。使われた計算資源や費用の記載もありません。

研究ページは、得られた知見を 2 つ挙げています。1 つは、テスト時の計算量とスキャナーの種類を増やすと、見つかる脆弱性が大きく増えることです。もう 1 つは、既存のバグを直すだけでは足りず、新しい脆弱性が混入する割合を下げる必要があることです。そのために、プルリクエストの時点でスキャンすることを勧めています。

開発側が確認すること

Anthropic は、防御側への助言として「自分のコードのスキャンは、これまで以上に重要になった」と述べています。強力なモデルを防御側が使えることは、攻撃者より先にシステムを修正する猶予を得るうえで重要だ、という立場です。

ここからは、公式の助言を自社の開発に読み替えた編集部の整理です。

1. 公式が勧めるとおり、プルリクエストの時点で脆弱性のスキャンを通す流れがあるかを確認する
2. 既存の指摘を直す担当と、新しい指摘を判断する担当を決めておく
3. OS とカーネルの更新の担当、確認の頻度、再起動の許可の取り方を決めておく
4. 外部に預けているシステムは、更新の責任がどちらにあるかを契約と運用の手順で確認する

継続的にコードをスキャンして修正を追跡する機能は、Claude Security の継続スキャンと修正追跡 で解説しています。外部の診断の費用と範囲の決め方は 脆弱性診断の費用相場、脆弱性を組織で継続管理する運用は 情報システムの脆弱性管理を ISMS で回す にあります。

FIXIT の運用｜預かるシステムの更新の責任を先に決める

本記事は公式情報に基づく解説です。FIXIT がこの脆弱性を検証した事例や、対応した実績を示すものではありません。

AI 駆動開発のクリエイティブスタジオである FIXIT は、システムを預ける側にも預かる側にも、OS・ミドルウェアの更新の責任と、再起動を許可する窓口を先に決めておくことを勧めています。更新の判断を誰が下すかが決まっていないと、修正が公表されてから対応を始めるまでに時間がかかるためです。生成 AI の利用ルールの整備や、社内の情報資産の棚卸しは、情報セキュリティコンサルタント として支援しています。

まとめ

Anthropic の研究は、公開されていない社内の研究モデルが、Linux・Chrome・Safari・Android・Windows の脆弱性を見つけ、攻撃を実演した内容です。Linux の CVE-2026-98432 は、MPTCP のリスナーを持つサーバーに対し、認証なしで root のコマンドを実行できた実演でした。深刻度 9.8 は Linux カーネルの CNA が付けた CVSS 3.1 の値で、Red Hat は 8.1 と評価しています。

読者の次の一歩は、使っているディストリビューションの、自分の版の状態を確認することです。MPTCP を使っているかどうかが分からなくても、修正版が出ている版は更新を進められます。更新の責任の分担や、開発側のスキャンの進め方を相談したい場合は、お問い合わせ からご連絡ください。