Linuxカーネル脆弱性・CVE急増問題の真相と対策｜AIエクスプロイト・CRA対応

Linuxサーバの脆弱性診断を行ったり、セキュリティ勧告を確認したりしていると、参照リンクとして https://docs.kernel.org/process/cve.html というURLを見かける機会が増えています。

同時に、インターネットやSNS上では「Linuxカーネルにroot権限を遠隔から奪取される致命的な脆弱性が見つかった」「毎週大量のCVEが発行され、脆弱性の調査が追いつかない」といった声も上がっています。

本記事では、2026年10月31日時点の公式ドキュメント、各Linuxディストリビューションのセキュリティ情報、公開された技術資料をもとに、LinuxカーネルのCVE急増問題と実際に発生している脆弱性について解説します。

結論からいうと、Linuxカーネルのコード品質が突然劣化したわけではありません。

Linuxカーネル開発コミュニティがCVE採番機関（CNA）となり、セキュリティ上の問題につながる可能性があるバグ修正にも積極的にCVEを割り当てる方針を採用したことが、大量発行の大きな要因です。

一方、2026年10月に公表されたIPv4 TCPスタックの脆弱性 CVE-2026-98432 では、AnthropicのAIモデルClaudeが遠隔からroot権限で任意のコマンドを実行するエクスプロイトを構築したことが公表されました。

これは、AIによる脆弱性の発見や攻撃コード生成が、現実のシステムに対する脅威になっていることを示す事例です。

この記事では、CVE急増の背景から、実際の脆弱性、OS別の対応状況、カーネル更新手順、パッチ適用までの暫定対策まで幅広く解説します。

この記事でわかること
対象読者・前提条件
まず結論：Linux環境で今すぐ確認すべきこと
前提知識：公式ドキュメント「process/cve.html」とCNA化の真相
1. 具体的に何が起きているのか？（技術的な実態）
2. OS・ディストリビューション別の対応状況
3. パッチ・バージョンアップによる正式な対応手順
4. パッチ未提供・即時更新不可の環境におけるワークアラウンド
5. EUサイバーレジリエンス法（CRA）とLinuxの脆弱性管理
1. 2026年9月11日から脆弱性の報告義務が開始
2. Linuxを組み込んだ製品にも影響する
6. LinuxカーネルのCVEを効率的に管理するための考え方
7. Linuxカーネルの脆弱性を報告する場合の窓口
よくある質問（FAQ）
まとめ：CVEスコア追従から継続的なカーネル管理へ
次に読むおすすめ記事
参考情報

この記事でわかること

Linuxカーネル公式ドキュメント process/cve.html の役割とCNA化の背景
CVE大量発行（CVE Flood）が発生している理由
CVSSスコアが付与されないCVEやベンダ間の評価差が生じる理由
AIが遠隔root奪取エクスプロイトを構築した CVE-2026-98432 の仕組み
Go 1.24以降のMPTCPデフォルト設定と脆弱性の関係
Ubuntu、Debian、RHEL、SUSE、Amazon Linuxなどの対応状況
正式なカーネル更新手順と注意点
パッチ未提供時に実施できるワークアラウンド
Yoctoなどの組込みLinuxで大量のCVEを効率的に管理する方法
EUサイバーレジリエンス法（CRA）への対応

対象読者・前提条件

対象読者：Linuxサーバ・クラウド基盤を運用するインフラエンジニア、脆弱性管理を担当するセキュリティ担当者、組込みLinux開発者
対象環境：Ubuntu、Debian、RHEL / AlmaLinux / Rocky Linux、SUSE、Amazon Linux、Yocto Project、Buildrootなど
情報基準日：2026年10月31日

※脆弱性の修正状況は日々更新されます。実際のアップデート時には、必ず利用しているOSベンダの最新セキュリティ情報を確認してください。

—

まず結論：Linux環境で今すぐ確認すべきこと

今回の問題に対して、Linux管理者が優先して確認すべき事項を整理します。

利用環境・状況	2026年10月末時点の状況	優先すべき対応
Debian 12 / 13	CVE-2026-98432修正済み	修正済みカーネルへ更新して再起動
Amazon Linux 2023	カーネルの種類によって対応状況が異なる	使用中のカーネルパッケージを確認
Ubuntu 22.04 / 24.04 / 26.04 / 26.10	修正作業中	Ubuntu Security Trackerを継続確認
RHEL 8 / 9 / 10	影響あり。修正は今後のアップデート待ち	Red Hatのセキュリティ速報を確認
Go 1.24以降のアプリケーション	MPTCPリスナーがデフォルトで有効	MPTCPの利用状況を確認し、必要に応じて無効化
Yocto・独自カーネル	ビルド構成によって影響範囲が異なる	CVE情報と実際のビルド構成を照合

特に CVE-2026-98432 は、MPTCPを使用していない環境でも脆弱性そのものが存在する点に注意してください。

MPTCPの無効化は、公開された特定の遠隔root奪取エクスプロイトに対する緩和策であり、カーネルの修正を代替するものではありません。

前提知識：公式ドキュメント「process/cve.html」とCNA化の真相

セキュリティツールのアラートなどで見かける process/cve.html は、個別の脆弱性を報告するページではありません。

Linuxカーネル開発プロジェクトが、自らCVEを割り当てるための公式な運用ポリシーと手順を定めたドキュメントです。

公式ページ：

CVEs — The Linux Kernel documentation

なぜLinuxカーネルチーム自身がCNAになったのか

CNAとは、CVE Numbering Authorityの略で、CVE番号を割り当てる権限を持つ組織です。

従来、Linuxカーネルの脆弱性は、外部のセキュリティ研究者や組織などがCVEを申請するケースもありました。

しかし、Linuxカーネルは世界中で利用されており、開発速度も非常に速いため、外部の機関だけで脆弱性を管理することには限界がありました。

そこで2024年2月、Linuxカーネル開発プロジェクト自身がCNAとして認定され、カーネルの脆弱性に関するCVE管理を主体的に行う体制へ移行しました。

過剰なまでに慎重なアプローチとCVE大量発行

CNAとなったLinuxカーネルチームが採用した方針は、従来の脆弱性管理とは少し異なります。

LinuxカーネルはOSの最下層で動作するため、通常のバグであっても、利用環境や攻撃条件によってはセキュリティ上の問題につながる可能性があります。

また、バグが修正された時点では、それが実際に悪用可能かどうかを判断できない場合もあります。

そのため、LinuxカーネルのCVE採番チームは、公式ドキュメントで「過剰なまでに慎重（overly cautious）」なアプローチを採用していると説明しています。

具体的には、通常のStableカーネルのリリースプロセスにおいて、セキュリティ上の問題となる可能性があると判断されたバグ修正にCVE番号を割り当てます。

重要なのは、すべてのバグ修正に無条件でCVEを割り当てるという意味ではないことです。

従来であれば通常のバグ修正として処理されていた変更にもCVEが付与されるようになったため、統計上の発行件数が大きく増加しました。

この現象は「CVE Flood」と呼ばれています。

現場を悩ませる「スコアなし」と「事後発行」のルール

LinuxカーネルのCVE管理で、もう一つ特徴的なのがCVSSスコアの扱いです。

CVSSとは、脆弱性の深刻度を数値で評価するための仕組みです。

一般的には0.0～10.0の範囲で評価され、数値が大きいほど深刻度が高くなります。

しかし、LinuxカーネルのCVE採番チームは、すべてのCVEに一律のCVSSスコアを付与していません。

その理由は、Linuxカーネルの利用環境が非常に多様だからです。

例えば、同じカーネルのバグであっても、以下の条件によって実際の危険性は変わります。

使用しているカーネルのバージョン
有効化されているCONFIGオプション
使用しているネットワークプロトコル
ロードされているカーネルモジュール
攻撃者が必要とする権限
外部ネットワークからアクセスできるか

そのため、アップストリーム側が一律の深刻度を評価することは難しく、各ディストリビューションが独自の基準で評価する場合があります。

また、Linuxカーネルでは、修正パッチがStableツリーに適用された後にCVEが公開されるケースがあります。

つまり、未修正のバグが存在している段階ではCVE番号が付いていないこともあります。

この仕組みにより、次のような問題が発生します。

脆弱性管理ツールのアラート増加

CVE番号が大量に発行されるため、管理者が個々の影響範囲を確認する負担が増えます。

ベンダ間の深刻度評価の違い

同じCVEでも、Ubuntu、Red Hat、Amazon LinuxなどでCVSSスコアや優先度が異なることがあります。

バージョン判定による誤検知

RHELなどでは、古いカーネルのバージョン番号を維持したまま修正をバックポートするため、単純なバージョン比較では修正済みなのに脆弱と判定される場合があります。

コンプライアンスとの衝突

CVEが存在するという理由だけでソフトウェアの使用を禁止すると、実際には影響を受けない環境まで更新対象となり、不要なアップグレードを強いられる可能性があります。

したがって、CVEの件数やCVSSスコアだけで対応の優先順位を決めるのではなく、実際の利用環境における影響を確認することが重要です。

—

1. 具体的に何が起きているのか？（技術的な実態）

現在のLinuxカーネルを取り巻く状況は、CVEの大量発行という運用上の問題と、実際に悪用可能な脆弱性という技術上の問題に分けて考える必要があります。

1-1. WARN_ON()とpanic_on_warnによるDoSの問題

Linuxカーネルには、異常な状態を検出するための WARN() や WARN_ON() というマクロがあります。

これらは、カーネル内部で想定外の状態が発生した場合に警告を出力する仕組みです。

通常、警告が発生してもカーネルは処理を継続します。

しかし、カーネルパラメータ panic_on_warn が有効になっている環境では、警告が発生した際にカーネルパニックを引き起こす場合があります。

例えば、次のような設定です。

sysctl kernel.panic_on_warn

値が 1 の場合、WARN発生時にカーネルパニックを起こす設定です。

このような環境では、ユーザー空間から到達可能なWARNの発生条件が、サービス停止につながる可能性があります。

そのため、WARN関連のバグ修正であっても、利用環境によってはセキュリティ上の問題として扱われます。

ただし、すべてのWARN関連修正が必ずDoS脆弱性になるわけではありません。

また、データ破損やファイルシステムの不具合にCVEが割り当てられるかどうかについても、一律のルールで判断することはできません。

CVEの割り当ては、個々の問題がセキュリティ上の脆弱性に該当するかどうかによって判断されます。

1-2. AIによるエクスプロイト自動生成

CVEの大量発行とは別に、2026年はAIによる脆弱性研究でも大きな変化がありました。

特に注目したいのが、AnthropicのClaudeを利用した脆弱性の発見とエクスプロイト構築です。

2026年3月には、FreeBSDの CVE-2026-4747 に関して、Claudeを利用した脆弱性発見事例が公表されています。

この脆弱性はRPCSEC_GSSのパケット検証処理におけるスタックバッファオーバーフローです。

また、2026年10月27日にはAnthropicのFrontier Red Teamが、Claudeを用いて複数の重要なソフトウェアの脆弱性を発見し、攻撃コードを構築した研究結果を公開しました。

その中でも特に注目されたのが、Linuxカーネルの CVE-2026-98432 です。

Anthropicの研究では、ClaudeがLinuxサーバにネットワーク経由でパケットを送信し、認証なしでroot権限による任意コマンド実行に至るエクスプロイトを構築しました。

これは、AIが単に脆弱性を指摘するだけでなく、実際に攻撃を成立させるコードまで作成できることを示しています。

代表的なLinuxカーネルの脆弱性

2025年から2026年に公開された脆弱性の中から、技術的に特徴のあるものを紹介します。

CVE番号	対象・脆弱性	概要・影響
CVE-2026-98432	IPv4 TCPスタック / Use-After-Free	TCP接続要求の処理中に発生する競合状態。Anthropicが遠隔root実行エクスプロイトを実証
CVE-2026-31431	暗号サブシステム / Copy Fail	AF_ALGとsplice()を悪用したローカル権限昇格。読み取り可能ファイルのページキャッシュを改ざんできる
CVE-2026-64561	KVM / シャドウMMU	無効化されたMMUルートに関連する処理不備。ゲストからホストへの攻撃につながる可能性
CVE-2026-99999	IPv4 / checksum_start	不正なチェックサムメタデータによる境界外書き込み。メモリ破壊につながる可能性
CVE-2026-98728	TPM2 / 境界チェック不備	乱数取得処理で切り詰められた応答の検証が不十分となり、バッファ外の情報を読み取る可能性
CVE-2026-99057	Xen netfront / メモリリーク	異常な応答チェーンの処理時にSKBと関連ページが解放されず、メモリリークが発生
CVE-2026-80693	Intel IDPF / 境界外書き込み	割り当てられた配列のサイズを超えてデータを書き込む可能性
CVE-2025-40240	SCTP / NULLポインタ参照	不正なポインタ参照によってカーネルクラッシュが発生する可能性

※CVE-2026-64561はZapscapeとして公開されたPoCが知られていますが、根本原因を単純なUse-After-Freeと分類するのは正確ではありません。

また、これらのCVEは影響範囲や攻撃条件がそれぞれ異なります。すべてが遠隔からroot権限を取得できる脆弱性というわけではありません。

CVE-2026-98432：AIが遠隔root奪取を実証した脆弱性

今回、特に注意したいのが CVE-2026-98432 です。

この脆弱性はLinuxカーネルのIPv4 TCP処理に存在するUse-After-Freeです。

Use-After-Freeとは、メモリが解放された後にも、そのメモリ領域を参照してしまう不具合です。

通常、メモリを解放した後は、その領域を参照してはいけません。

しかし、複数のCPUが同時に処理を行う環境でタイミングが重なると、解放済みのメモリを別の処理が参照してしまうことがあります。

今回の問題では、TCP接続要求の処理中にIPオプションを保持するメモリが解放されるタイミングと、別のCPUによる再送SYN処理などが競合することで、Use-After-Freeが発生します。

修正では、メモリを直ちに解放するのではなく、RCU（Read-Copy-Update）の猶予期間が経過した後に解放する kfree_rcu() などの仕組みが利用されています。

Anthropicが実証した攻撃の仕組み

Anthropicの研究では、Claudeが次のような段階を経て攻撃コードを構築しました。

TCP接続要求の処理に存在する競合状態を利用する。
メモリの読み取りを通じてカーネルのアドレス情報を取得し、KASLRを回避する。
Use-After-Freeを再利用してカーネルの制御フローを操作する。
ROPなどの技術を利用してカーネル内の処理を連鎖させる。
最終的にroot権限で任意のコマンドを実行する。

Anthropicの実証では、MPTCPリスナーを持つLinuxサーバが攻撃対象になっています。

重要なのは、MPTCPそのものに脆弱性があるわけではないことです。

根本原因はIPv4 TCPの処理に存在するため、MPTCPを無効化しただけでカーネルの脆弱性がなくなるわけではありません。

CVSSスコアの違い

同じCVEでも、評価機関によって深刻度が異なります。

評価元	評価
LinuxカーネルCNA	CVSS 9.8
Ubuntu	CVSS 9.8 / High priority
Red Hat CVE情報ページ	CVSS 5.9 / Moderate
Red Hat RHSB-2026-016	Critical Impact

Red HatのCVE情報ページでは、競合状態を成立させる難易度が高く、実証された影響が主にDoSであることを理由に5.9と評価しています。

一方、2026年10月30日に公開されたセキュリティ速報 RHSB-2026-016 では、遠隔コード実行の可能性を含めてCritical Impactとして警告しています。

このように、CVE情報ページと個別のセキュリティ速報では評価の前提や更新状況が異なることがあります。

また、今回確認できたRed Hatの公式情報では、8.1への変更を確定情報として扱うことはできません。

したがって、特定のCVSSスコアだけで危険性を判断せず、ベンダの最新セキュリティ速報も確認することが重要です。

参考：

https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
https://access.redhat.com/security/cve/cve-2026-98432
https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
https://ubuntu.com/security/CVE-2026-98432

—

2. OS・ディストリビューション別の対応状況

ここからは、実際にLinuxを運用している管理者が確認すべきOS別の対応状況を整理します。

対象は、遠隔root実行が実証された CVE-2026-98432 です。

OS別の対応状況（2026年10月31日時点）

OS・環境	対象バージョン	対応状況
アップストリームLinux	Stable / LTS	修正済み
Debian	12 / 13	修正済み
Ubuntu	26.10 / 26.04 / 24.04 / 22.04	修正作業中
Ubuntu	20.04 / 18.04 / 16.04	影響あり。各サポート契約・ESM状況の確認が必要
RHEL	8 / 9 / 10	影響あり。修正パッケージ待ち
RHEL	7	該当する脆弱なコードが存在せず影響なし
RHEL	6	サポート対象外
Amazon Linux 2023	標準kernel	修正待ち
Amazon Linux 2023	kernel6.12 / kernel6.18	修正済み
SUSE	製品・SP別	一部修正済み、一部準備中

※RHEL系クローンや派生ディストリビューションについては、RHELと同じ状況だと決めつけず、各ベンダの公式情報を確認してください。

アップストリームの修正済みバージョン

kernel.orgのStable/LTSブランチでは、以下のバージョンで修正されています。

カーネル系列	修正済みバージョン
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.56
7.2	7.2.10
7.3	7.3系列

これらはアップストリームのバージョンです。

UbuntuやRHELなどのディストリビューションでは、古いバージョン番号のまま修正がバックポートされることがあるため、単純に uname -r の数値だけで判断しないでください。

Debian

Debian 12（bookworm）とDebian 13（trixie）では、修正済みパッケージが提供されています。

確認すべきパッケージの目安は以下のとおりです。

Debian 12：6.1.190-1以降
Debian 13：6.12.113-1以降

Debianでは、Security TrackerでCVEごとの対応状況を確認できます。

CVE-2026-98432

Ubuntu

2026年10月31日時点では、Ubuntu 26.10、26.04、24.04、22.04などの主要バージョンで修正作業中となっています。

Ubuntuは独自のカーネルパッケージを提供しているため、アップストリームの修正済みバージョンと単純比較することはできません。

公式情報：

CVE-2026-98432 | Ubuntu

Ubuntu is an open source software operating system that runs from the desktop, to the cloud, to all your internet connec…

パッケージのStatusがWork in progressからReleasedに変わったことを確認してから更新してください。

Red Hat Enterprise Linux

Red HatではRHEL 8、9、10などが影響対象です。

2026年10月30日に公開されたセキュリティ速報ではCritical Impactとして扱われています。

修正パッケージについては、今後のRed Hatのアップデート情報を確認してください。

また、RHEL 7は脆弱なコードが存在しないため影響なしとされていますが、RHEL 6はサポート対象外です。

サポート対象外と影響なしは意味が異なるため、混同しないようにしてください。

公式情報：

RHSB-2026-016 Use-after-free – kernel IPv4 (CVE-2026-98432) | Red Hat Customer Portal

Access Red Hat’s knowledge, guidance, and support through your subscription.

Amazon Linux 2023

Amazon Linux 2023では、カーネルパッケージの種類によって修正状況が異なります。

カーネルパッケージ	対応状況
標準kernel	Pending Fix
kernel6.12	修正済み
kernel6.18	修正済み

修正済みのアドバイザリには次のものがあります。

ALAS2023-2026-3335
ALAS2023-2026-3251

Amazon Linux 2023を使用している場合は、標準kernelを使用しているのか、追加のカーネルパッケージを使用しているのかを確認してください。

単純に dnf upgrade を実行すればすべてのカーネル構成が修正されるとは限りません。

公式情報：

CVE-2026-98432

SUSE

SUSEでは、製品やサービスパックごとに対応状況が異なります。

SUSE Linux MicroやopenSUSE Leapなどで修正版が提供されている場合もありますが、SLESの各サービスパックについては個別のセキュリティアドバイザリを確認してください。

公式情報：

SUSE Customer Portal

Android

AndroidでもLinuxカーネルを利用していますが、Android固有のドライバや独自の変更が含まれるため、一般的なUbuntuやDebianと同じ方法で管理することはできません。

例えば、CVE-2026-58731 はAndroidの physmem_extmem_linux.c に関連する境界外読み取りの問題です。

これはAndroidのセキュリティ情報として扱うべきものであり、Linuxカーネル一般の脆弱性と混同しないようにしてください。

Android端末の場合は、GoogleのAndroid Security Bulletinや端末メーカーのセキュリティアップデートを確認してください。

組込みLinux・IoT

Yocto ProjectやBuildrootを利用した組込みLinuxでは、一般的なディストリビューションとは異なる問題があります。

組込みLinuxでは、SoCベンダが提供するBSP（Board Support Package）をベースにカーネルを構築している場合が多く、アップストリームの修正がそのまま利用できるとは限りません。

また、製品ごとに有効化されているドライバやカーネル機能が異なるため、CVEが存在しても実際には影響を受けない場合があります。

一方で、ベンダのパッチ提供が遅れると、長期間脆弱なカーネルを使用し続けることになります。

このような環境では、カーネルのバージョンだけでなく、ビルド構成や適用済みパッチを含めた管理が必要です。

—

3. パッチ・バージョンアップによる正式な対応手順

脆弱性への最も確実な対策は、修正済みカーネルを適用することです。

ワークアラウンドはあくまで暫定対策であり、正式な修正パッチの適用を優先してください。

カーネル更新時の注意点：個別パッチの安易なチェリーピックを避ける

Linuxカーネルの修正パッチを適用する際に注意したいのが、個別のCVE修正コミットだけを抜き出して適用する行為です。

これをチェリーピックと呼びます。

カーネルのGitコミットは、複数の変更が相互に依存している場合があります。

そのため、ある修正だけを古いカーネルに適用すると、前提となる処理が不足していたり、別の不具合を引き起こしたりする可能性があります。

もちろん、十分な検証を行った上で個別バックポートを実施するケースはあります。

しかし、一般的なサーバ管理者が独自にパッチを抜き出して適用することはおすすめしません。

基本的には、ディストリビューションが提供する修正済みパッケージを使用してください。

また、CVE番号が付いていない通常のバグ修正にも重要な変更が含まれる場合があります。

CVEの有無だけでカーネルの更新対象を判断するのではなく、ベンダが提供するカーネル更新を定期的に適用することが重要です。

手順1：Ubuntu / Debianの更新

まず現在のカーネルバージョンを確認します。

uname -r

Ubuntuでは、必要に応じて次のコマンドでセキュリティメンテナンスの状態も確認できます。

pro security-status

パッケージ情報を更新します。

sudo apt update

システム全体をアップグレードします。

sudo apt --with-new-pkgs upgrade -y

更新後、システムを再起動します。

sudo reboot

再起動後、再度カーネルバージョンを確認します。

uname -r

注意点として、UbuntuではCVE-2026-98432の修正パッケージが未提供の状態では、上記のコマンドを実行しても今回の脆弱性が修正されるわけではありません。

必ずUbuntu Security Trackerで対象パッケージのStatusを確認してください。

手順2：RHEL / AlmaLinux / Rocky Linux / Amazon Linuxの更新

RPM系ディストリビューションでは、次のように確認・更新します。

現在のカーネルを確認します。

uname -r

セキュリティアドバイザリを確認します。

sudo dnf updateinfo list security

カーネルパッケージを更新します。

sudo dnf upgrade -y kernel

更新後、再起動します。

sudo reboot

再起動後にカーネルバージョンを確認します。

uname -r

ただし、Amazon Linux 2023のようにカーネルパッケージの種類によって対応状況が異なる場合は、利用中のパッケージを確認してから更新してください。

kpatchによるライブパッチについて

RHELでは、kpatchによるライブパッチ機能を利用できる場合があります。

ライブパッチとは、システムを再起動せずに実行中のカーネルへ修正を適用する仕組みです。

ただし、すべての脆弱性にライブパッチが提供されるわけではありません。

今回のCVE-2026-98432についても、対象カーネル向けの修正済みライブパッチが提供されているかを確認する必要があります。

ライブパッチが存在しない場合は、通常のカーネル更新と再起動が必要です。

—

4. パッチ未提供・即時更新不可の環境におけるワークアラウンド

修正パッチがまだ提供されていない場合や、本番稼働中で即座に再起動できない場合は、暫定的な緩和策を検討する必要があります。

ただし、今回のCVE-2026-98432については、すべての攻撃経路を確実に防止できるワークアラウンドが確認されているわけではありません。

以下は、既知の攻撃経路への露出を減らすための対策です。

ワークアラウンド1：MPTCPを無効化する

今回のAIによる遠隔root奪取の実証では、MPTCPリスナーを持つLinuxサーバが攻撃対象になっています。

MPTCPとは、複数のネットワーク経路を利用して通信できるTCPの拡張機能です。

通常のTCPとは異なり、複数のネットワークインターフェースなどを活用できる特徴があります。

Go 1.24では、Linux上のTCPリスナーにおいてMPTCPがデフォルトで有効になる仕様変更が行われました。

そのため、開発者が明示的にMPTCPを有効にしたつもりがなくても、Go製アプリケーションがMPTCPリスナーを使用している可能性があります。

方法A：OS全体でMPTCPを無効化する

まず現在の設定を確認します。

sysctl net.mptcp.enabled

MPTCPを無効化します。

sudo sysctl -w net.mptcp.enabled=0

再起動後も設定を維持するには、設定ファイルを作成します。

echo "net.mptcp.enabled = 0" | \
sudo tee /etc/sysctl.d/90-disable-mptcp.conf

設定を反映します。

sudo sysctl --system

ただし、OSやカーネルのバージョンによって対応状況が異なる場合があります。

また、MPTCPを利用しているアプリケーションやネットワーク構成に影響する可能性があるため、適用前に確認してください。

方法B：Go 1.24以降のアプリケーションでMPTCPを無効化する

Go 1.24以降では、GODEBUG によってMPTCPのデフォルト動作を変更できます。

例えば、次のように設定します。

export GODEBUG=multipathtcp=0

その後、アプリケーションを起動します。

./my-go-server

systemdで管理している場合は、ユニットファイルの [Service] セクションに次の設定を追加します。

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

変更後、設定を再読み込みしてアプリケーションを再起動します。

sudo systemctl daemon-reload
sudo systemctl restart my-app

また、Goのメインモジュールの go.mod に以下を記述して再ビルドする方法もあります。

godebug multipathtcp=0

ソースコードに以下のディレクティブを記述する方法もあります。

//go:debug multipathtcp=0

package main

重要なのは、MPTCPの無効化によって防げるのは、Anthropicが実証した特定の攻撃経路だということです。

根本原因は通常のIPv4 TCP処理にあるため、MPTCPを無効化しただけで脆弱性そのものが解消されるわけではありません。

参考：

Go, Backwards Compatibility, and GODEBUG – The Go Programming Language

ワークアラウンド2：IPv4 IPオプション付きTCPパケットを遮断する

Red Hatは、CVE-2026-98432への暫定的な緩和策として、IPv4のIPオプションを含むTCPパケットを遮断する方法を公開しています。

通常のIPv4ヘッダーは20バイトです。

IPオプションが付与されるとヘッダー長が20バイトより大きくなります。

今回の脆弱性では、このようなIPオプションを含むTCPパケットが関係するため、対象パケットを遮断することで既知の攻撃経路への露出を低減できます。

nftablesを使用する場合

Red Hatが公開している設定例です。

まず、設定ファイルを作成します。

sudo tee cve-2026-98432.nft <<'EOF'
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
EOF

構文を確認します。

sudo nft --check --file cve-2026-98432.nft

問題がなければ適用します。

sudo nft --file cve-2026-98432.nft

設定を確認します。

sudo nft list table inet cve_2026_98432

カーネルの修正が完了した後、暫定ルールを削除する場合は次のコマンドを実行します。

sudo nft delete table inet cve_2026_98432

この設定はIPv4のIPオプション付きTCPパケットを遮断するものです。

通常のTCPオプションはTCPヘッダー内にあるため、このルールの対象とは異なります。

ただし、特殊なネットワーク構成やIPオプションを利用するアプリケーションでは通信に影響する可能性があります。

必ず検証環境で確認してから本番環境に適用してください。

また、この方法は脆弱性の完全な解消を保証するものではありません。

iptablesを使用している場合

iptablesを利用している環境では、ファイアウォールによる通信制御を検討できます。

ただし、Red Hatが今回の緩和策として公開しているのは、上記のnftablesルールです。

独自のiptablesルールを同等の対策として安易に適用せず、使用しているiptablesのバックエンドやルール構成を確認してください。

ワークアラウンド3：不要なネットワークサービスを外部公開しない

今回の脆弱性はIPv4 TCPの接続処理に関係します。

そのため、外部からアクセスできるTCPサービスを必要最小限にすることも重要です。

例えば、以下のような対策が考えられます。

使用していないTCPポートを閉じる。
SSHの接続元IPアドレスを制限する。
管理用ネットワークと公開用ネットワークを分離する。
ファイアウォールで不要な通信を遮断する。
外部公開サーバの前段にロードバランサやリバースプロキシを配置する。

ただし、TCP接続そのものを受け付けるサーバでは、アプリケーションの認証処理より前にカーネルがパケットを処理します。

そのため、アプリケーション側のログイン認証を強化するだけでは今回の脆弱性への対策にはなりません。

ワークアラウンド4：不要なカーネルモジュールを無効化する

使用していないネットワークプロトコルやカーネルモジュールを無効化することは、一般的な攻撃対象領域（Attack Surface）の縮小につながります。

例えば、業務でSCTPやBluetoothなどを使用していない場合は、利用状況を確認した上で無効化を検討できます。

現在ロードされているモジュールは次のコマンドで確認できます。

lsmod

特定のモジュールの情報は次のように確認します。

modinfo sctp

ただし、モジュールを無効化する場合は次の点に注意してください。

他のモジュールから依存されていないか確認する。
カーネルに組み込まれている機能はmodprobe設定だけでは無効化できない。
既にロードされているモジュールは設定変更だけでは停止しない。
アプリケーションやネットワーク機能に影響しないか検証する。

また、CVE-2026-31431 のCopy Failについては、AF_ALG関連の機能が関係しますが、単純に一つのモジュールを無効化すればすべての環境で防御できると考えるべきではありません。

ワークアラウンド5：カーネルのセキュリティ設定を見直す

今回の脆弱性に直接対応するものではありませんが、Linuxサーバの基本的なセキュリティ設定を見直すことも重要です。

例えば、以下のような設定があります。

# 非特権ユーザによるカーネルポインタ情報の取得を制限
kernel.kptr_restrict = 2

# 非特権ユーザによるdmesgの閲覧を制限
kernel.dmesg_restrict = 1

# 非特権ユーザによるeBPFの利用を制限
kernel.unprivileged_bpf_disabled = 1

# perfイベントの利用を制限
kernel.perf_event_paranoid = 3

これらの設定を /etc/sysctl.d/99-kernel-hardening.conf などに保存し、次のコマンドで反映できます。

sudo sysctl --system

ただし、これらは一般的なカーネルのハードニング設定です。

CVE-2026-98432の根本原因を修正するものではありません。

また、eBPFやperfなどを業務で使用している場合は、設定によって機能に影響する可能性があるため、事前に確認してください。

なお、kernel.panic_on_warn = 0 を一律に推奨することは適切ではありません。

WARN発生時に処理を継続するか停止するかは、システムの安全性や可用性を考慮して判断する必要があります。

ワークアラウンド6：vulns.gitとビルド構成によるCVEトリアージ

Yocto ProjectやOpenEmbeddedなどを利用した組込みLinuxでは、大量のCVEを人手で調査することが大きな負担になります。

そこで活用したいのが、Linuxカーネル公式の脆弱性管理リポジトリです。

LF git repositories

Browse git repositories hosted by the Linux Foundation.

このリポジトリには、LinuxカーネルのCVE情報や影響範囲、修正コミットなどが管理されています。

まずはリポジトリを取得します。

git clone https://git.kernel.org/pub/scm/linux/security/vulns.git

cd vulns

CVE情報を確認することで、どのカーネルバージョンやコミットが影響を受けるかを調査できます。

特にカスタムカーネルでは、単純なバージョン比較だけでなく、実際に使用しているソースコードやビルド構成を確認することが重要です。

Yocto ProjectのCVEチェック

Yocto Projectには、ビルド対象のソフトウェアに対してCVE情報を確認する cve-check の仕組みがあります。

また、SBOM（Software Bill of Materials）を生成して、使用しているソフトウェアや構成情報を管理することもできます。

例えば、次のような設定があります。

INHERIT += "cve-check"

さらに、ビルド時に実際にコンパイルされたソースファイルの情報をSBOMに含めるには、次の設定を利用できます。

SPDX_INCLUDE_COMPILED_SOURCES = "1"

これらを活用することで、単純なバージョン判定だけでは把握しにくいカスタムビルド環境の影響範囲を調査しやすくなります。

ただし、CVEの影響有無を判断するには、以下の情報を総合的に確認する必要があります。

CVE情報に記載された影響対象ファイル
実際のビルド対象となったソースコード
カーネルの .config による機能の有効・無効
適用済みの修正パッチ
実際にロードされるモジュールや実行環境

コンパイルされていないファイルに関するCVEを除外できる場合はありますが、それだけでシステム全体が安全と判断できるわけではありません。

また、CVEチェックの結果は、EU CRAへの対応における技術的な記録として活用できますが、それだけで法的な要件を満たすわけではありません。

—

5. EUサイバーレジリエンス法（CRA）とLinuxの脆弱性管理

Linuxを利用する製品や組込み機器を開発している企業にとって、EUサイバーレジリエンス法（CRA）への対応も重要です。

CRAは、EU域内で販売されるデジタル要素を持つ製品のサイバーセキュリティ要件を定めた法律です。

2024年12月に発効し、製品のセキュリティ設計、脆弱性対応、アップデートなどについて製造業者に義務を課しています。

2026年9月11日から脆弱性の報告義務が開始

CRAでは、2026年9月11日から、悪用が確認された脆弱性や重大なセキュリティインシデントについて報告義務が開始されました。

主な報告期限は以下のとおりです。

報告内容	期限
早期警告	認知から24時間以内
詳細通知	認知から72時間以内
悪用確認済み脆弱性の最終報告	是正措置が利用可能になってから14日以内
重大なセキュリティインシデントの最終報告	72時間以内の詳細通知から1か月以内

報告はCRA Single Reporting Platform（SRP）を通じて行います。

製造業者は、原則として管轄CSIRTに報告し、情報はENISAにも共有されます。

なお、オープンソースソフトウェアの管理者（OSS Stewards）に対する関連する報告義務は、2027年12月11日から適用される予定です。

Linuxを組み込んだ製品にも影響する

例えば、以下のような製品が対象となる可能性があります。

ネットワークルーター
NAS
監視カメラ
IoT機器
産業用制御機器
Linuxを利用した組込み機器
Linuxベースのネットワーク製品

製品の製造業者は、使用しているLinuxカーネルの脆弱性を把握し、必要な修正を提供できる体制を整える必要があります。

特に組込みLinuxでは、SoCベンダやBSP提供元の対応が遅れることもあるため、製品開発段階から脆弱性管理を組み込むことが重要です。

参考：

Cyber Resilience Act – Reporting obligations

As of 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents im…

—

6. LinuxカーネルのCVEを効率的に管理するための考え方

大量のCVEが発行されるようになった現在、個々のCVEを一つずつ調査するだけでは管理負担が大きくなります。

重要なのは、CVEの数ではなく、自社のシステムに実際の影響があるかどうかを判断することです。

CVSSスコアだけで優先順位を決めない

CVSSスコアは脆弱性の深刻度を判断するための重要な指標です。

しかし、実際の攻撃リスクは、システムの構成や利用環境によって変わります。

例えば、次のような違いがあります。

確認項目	判断する内容
攻撃経路	ネットワーク経由か、ローカルアクセスが必要か
必要な権限	認証なしで攻撃可能か、一般ユーザー権限が必要か
機能の有効状態	該当するドライバやプロトコルが有効か
外部公開状況	インターネットからアクセスできるか
修正状況	ベンダが修正パッチを提供しているか
悪用状況	実際の攻撃やPoCが確認されているか

特に、今回の CVE-2026-98432 のように、AIによって実際のエクスプロイトが構築された事例では、CVSSだけでなく攻撃の成立条件を確認することが重要です。

ディストリビューションの公式情報を優先する

Ubuntu、Debian、RHELなどのディストリビューションでは、独自のカーネルパッケージを提供しています。

そのため、アップストリームのカーネルバージョンと単純に比較するのではなく、各ベンダのセキュリティ情報を確認してください。

例えば、以下の情報源があります。

Ubuntu Security Tracker
Debian Security Tracker
Red Hat CVE Database
Amazon Linux Security Center
SUSE Security Advisories

また、ベンダがVEX（Vulnerability Exploitability eXchange）などの情報を提供している場合は、実際の影響有無を判断する際に活用できます。

カーネルの鮮度を維持する

CVEの件数やスコアだけに振り回されないためには、サポートが継続しているカーネルを利用し、定期的に更新することが重要です。

特に、以下の運用を推奨します。

サポート対象のStable/LTSカーネルを利用する。
ディストリビューションのセキュリティアドバイザリを定期的に確認する。
修正済みカーネルパッケージを計画的に適用する。
再起動後に実際の稼働カーネルを確認する。
使用していないカーネル機能やモジュールを整理する。
カスタムカーネルではビルド構成と適用済みパッチを記録する。

個々のCVEに対する対応だけでなく、カーネル全体を継続的に保守する体制が必要です。

—

7. Linuxカーネルの脆弱性を報告する場合の窓口

自社の検証中にLinuxカーネルの未修正バグを発見した場合や、既存のCVE情報に誤りがある場合は、適切な窓口へ報告する必要があります。

Linuxカーネルでは、問題の種類によって報告先が異なります。

ケース	報告先・方法
公開済み修正パッチへのCVE採番漏れ	cve@kernel.org
外部機関による不適切なCVE採番	cve@kernel.org
CVEの内容や影響範囲の修正	該当サブシステムのメンテナ、必要に応じてcve@kernel.org
未修正のセキュリティバグ	security-bugs.htmlに従い、該当メンテナやsecurity@kernel.orgへ非公開で報告

未修正のセキュリティバグを報告する場合は、一般公開のメーリングリストへ詳細を送信しないようにしてください。

報告時には、以下の情報を整理すると調査が進みやすくなります。

影響するカーネルのバージョンやコミット
問題が発生する条件
再現方法
再現に必要なカーネル設定
想定されるセキュリティ上の影響

再現コードが用意できない場合でも、直ちに脆弱性ではないと判断されるわけではありません。

また、AIを使って発見・分析した問題についても、最終的には人間が内容を検証し、適切な形式で報告する必要があります。

公式情報：

Security bugs — The Linux Kernel documentation

—

よくある質問（FAQ）

Q1：Linuxカーネルの脆弱性が急増したのは、コードの品質が悪くなったからですか？

いいえ。コード品質が突然悪化したわけではありません。

2024年2月にLinuxカーネル開発プロジェクトがCNAとなり、セキュリティ上の問題につながる可能性があるバグ修正にも積極的にCVEを割り当てるようになったことが、大量発行の大きな理由です。

そのため、以前であれば通常のバグ修正として扱われていた変更にもCVE番号が付くようになり、統計上の件数が増加しています。

Q2：LinuxのCVEが大量に発行された場合、すべて修正しなければいけませんか？

CVEが存在するからといって、必ずしもすべての環境で同じ対応が必要になるわけではありません。

使用しているカーネルの構成や有効化されている機能によって、実際の影響は異なります。

ただし、影響がないと判断する場合も、ベンダの公式情報やビルド構成などを確認した上で判断してください。

Q3：RHELなどでuname -rのバージョンが古い場合、脆弱なままなのでしょうか？

必ずしもそうではありません。

RHELなどでは、古いバージョン番号を維持したまま修正パッチをバックポートすることがあります。

そのため、uname -r の数値だけで判断することはできません。

利用しているディストリビューションのセキュリティアドバイザリを確認してください。

Q4：CVE-2026-98432はMPTCPを無効化すれば安全になりますか？

いいえ。

Anthropicが実証した遠隔root奪取エクスプロイトではMPTCPリスナーが利用されています。

そのため、MPTCPを無効化することで、公開された特定の攻撃経路を塞ぐことはできます。

しかし、脆弱性の根本原因はIPv4 TCP処理にあるため、MPTCPを無効化しただけで脆弱性そのものが解消されるわけではありません。

修正済みカーネルへの更新が最も重要です。

Q5：Go 1.24以降を使っている場合は、必ずMPTCPを無効化すべきですか？

まずはMPTCPの利用状況を確認してください。

Go 1.24では、MPTCPがTCPリスナーでデフォルト有効となる仕様変更が行われています。

MPTCPを利用する必要がないアプリケーションでは、GODEBUG=multipathtcp=0 によって無効化することを検討できます。

ただし、これは今回の脆弱性に対する暫定的な緩和策です。

Q6：パッチが提供されるまで再起動できない場合はどうすればよいですか？

まず、ネットワークからのアクセス制限や不要なTCPサービスの停止を検討してください。

また、Red Hatが公開しているnftablesによるIPv4 IPオプション付きTCPパケットの遮断も、暫定的な緩和策として検討できます。

Go 1.24以降のアプリケーションでは、MPTCPの無効化も有効です。

ただし、いずれも正式な修正パッチの代替ではありません。

Q7：カーネルの修正パッチを個別にチェリーピックしてもよいですか？

一般的な運用ではおすすめしません。

カーネルの修正には複数のコミットが依存している場合があり、個別に抜き出すと新しい不具合を引き起こす可能性があります。

基本的にはディストリビューションが提供する修正済みパッケージを使用してください。

Q8：Yoctoなどの組込みLinuxでは何を確認すればよいですか？

使用しているカーネルのバージョンだけでなく、以下を確認してください。

.config による機能の有効・無効
実際にコンパイルされたソースファイル
適用済みのバックポートパッチ
ロードされるカーネルモジュール
BSP提供元のセキュリティ情報

Yoctoの cve-check やSBOM生成機能を活用すると、脆弱性管理を効率化できます。

—

まとめ：CVEスコア追従から継続的なカーネル管理へ

LinuxカーネルのCVE急増問題の本質は、Linuxそのものが突然危険になったということではありません。

Linuxカーネル開発プロジェクトがCNAとなり、従来よりも広い範囲でCVEを割り当てるようになったことで、脆弱性管理の運用方法を見直す必要が生じています。

一方で、2026年10月に公表された CVE-2026-98432 のように、AIが実際に遠隔root奪取エクスプロイトを構築できる事例も登場しています。

今後は、脆弱性の発見から攻撃コードの生成までの時間が短縮される可能性も考慮しなければなりません。

Linuxを安全に運用するためには、次の3つが重要です。

修正済みカーネルを速やかに適用する

Ubuntu、Debian、RHELなど、使用しているディストリビューションの公式セキュリティ情報を確認し、修正パッケージを適用します。

パッチ適用までの暫定対策を実施する

MPTCPの無効化、IPオプション付きTCPパケットの遮断、不要なネットワークサービスの停止などを検討します。ただし、暫定対策を正式な修正の代わりにしてはいけません。

CVEの件数ではなく実際の影響を評価する

CVSSスコアだけでなく、カーネル構成、使用機能、攻撃経路、ベンダの修正状況を確認します。Yoctoなどの組込み環境では、ビルド構成やSBOMも活用します。

CVEの大量発行によるアラート疲れを防ぎながら、実際に危険な脆弱性を見逃さない運用体制を構築することが重要です。

—

次に読むおすすめ記事

LinuxやUbuntuの基本操作、初期設定、セキュリティ対策、パッケージ更新について詳しく知りたい方は、以下の記事も参考にしてください。

この記事でわかること

対象読者・前提条件

まず結論：Linux環境で今すぐ確認すべきこと

前提知識：公式ドキュメント「process/cve.html」とCNA化の真相

なぜLinuxカーネルチーム自身がCNAになったのか

過剰なまでに慎重なアプローチとCVE大量発行

現場を悩ませる「スコアなし」と「事後発行」のルール

1. 具体的に何が起きているのか？（技術的な実態）

1-1. WARN_ON()とpanic_on_warnによるDoSの問題

1-2. AIによるエクスプロイト自動生成

代表的なLinuxカーネルの脆弱性

CVE-2026-98432：AIが遠隔root奪取を実証した脆弱性

Anthropicが実証した攻撃の仕組み

CVSSスコアの違い

2. OS・ディストリビューション別の対応状況

OS別の対応状況（2026年10月31日時点）

アップストリームの修正済みバージョン

Debian

Ubuntu

Red Hat Enterprise Linux

Amazon Linux 2023

SUSE

Android

組込みLinux・IoT

3. パッチ・バージョンアップによる正式な対応手順

カーネル更新時の注意点：個別パッチの安易なチェリーピックを避ける

手順1：Ubuntu / Debianの更新

手順2：RHEL / AlmaLinux / Rocky Linux / Amazon Linuxの更新

kpatchによるライブパッチについて

4. パッチ未提供・即時更新不可の環境におけるワークアラウンド

ワークアラウンド1：MPTCPを無効化する

方法A：OS全体でMPTCPを無効化する

方法B：Go 1.24以降のアプリケーションでMPTCPを無効化する

ワークアラウンド2：IPv4 IPオプション付きTCPパケットを遮断する

nftablesを使用する場合

iptablesを使用している場合

ワークアラウンド3：不要なネットワークサービスを外部公開しない

ワークアラウンド4：不要なカーネルモジュールを無効化する

ワークアラウンド5：カーネルのセキュリティ設定を見直す

ワークアラウンド6：vulns.gitとビルド構成によるCVEトリアージ

Yocto ProjectのCVEチェック

5. EUサイバーレジリエンス法（CRA）とLinuxの脆弱性管理

2026年9月11日から脆弱性の報告義務が開始

Linuxを組み込んだ製品にも影響する

6. LinuxカーネルのCVEを効率的に管理するための考え方

CVSSスコアだけで優先順位を決めない

ディストリビューションの公式情報を優先する

カーネルの鮮度を維持する

7. Linuxカーネルの脆弱性を報告する場合の窓口

よくある質問（FAQ）

Q1：Linuxカーネルの脆弱性が急増したのは、コードの品質が悪くなったからですか？

Q2：LinuxのCVEが大量に発行された場合、すべて修正しなければいけませんか？

Q3：RHELなどでuname -rのバージョンが古い場合、脆弱なままなのでしょうか？

Q4：CVE-2026-98432はMPTCPを無効化すれば安全になりますか？

Q5：Go 1.24以降を使っている場合は、必ずMPTCPを無効化すべきですか？

Q6：パッチが提供されるまで再起動できない場合はどうすればよいですか？

Q7：カーネルの修正パッチを個別にチェリーピックしてもよいですか？

Q8：Yoctoなどの組込みLinuxでは何を確認すればよいですか？

まとめ：CVEスコア追従から継続的なカーネル管理へ

次に読むおすすめ記事

参考情報

Linuxカーネル公式情報

CVE-2026-98432関連情報

その他の脆弱性情報

Go・組込みLinux・EU CRA