CVE-2026-98432が示す教訓：LinuxカーネルRCE脆弱性をAIで早期検知する方法

公開日：2026年11月5日文：クリスタルメソッド編集部監修：河合継（代表取締役）

CVE-2026-98432：Linuxカーネルを直撃したCritical脆弱性の要点

2026年10月15日、LinuxカーネルのIPv4 TCP処理に存在するuse-after-free脆弱性がCVE-2026-98432として公開された。CVSSスコアは9.8（Critical）で、影響範囲はカーネルv4.4以降——Ubuntu・RHEL・Rocky Linuxを含む広範なディストリビューションが対象に含まれる（Cryptika Cybersecurity）。

技術的な核心は競合状態にある。MPTCPリスナーが有効な環境ではリモートからのroot実行が実証されており、Anthropic Frontier Red Teamが2026年10月27日に公開した研究では、未公開のClaudeモデルがKASLRバイパスからrootシェル取得まで約53分で到達したことが報告されている（Cryptika Cybersecurity / BleepingComputer）。エクスプロイト自体は未公開で、ラボ環境でのテストに限られる。

さらに、セキュリティ研究者のMarcus Hutchinsは2026年11月2日にX上でインターネット全体への積極的スキャンを報告しており、住宅用プロキシやロシアベースVPNを用いた分散スキャンが観測されている（Cryptika Cybersecurity）。CVE公開から最初のスキャン活動確認まで18日。この速度は、今回に特有のことではなく、脆弱性対応に求められる体制そのものを問い直している。

なぜ18日でスキャンが始まるのか——課題の構造

CVE公開から攻撃偵察開始までの時間は、過去5年で着実に短縮されている傾向がある。PoC（概念実証コード）が出回る速度が上がり、攻撃者側が脆弱性情報を即座に解析してスキャナに組み込む環境が整っている。パッチ適用のための実質的な猶予は、数週間ではなく数日単位で考えるべき状況になっている、と現場のセキュリティ担当者の間では認識されつつある。

問題の根にあるのは資産管理の粗さだ。今回のケースでは、「自社のサーバーがMPTCPを有効にしているかどうか」すら即座に答えられない組織が多い。Ubuntu 22.04・24.04向けパッチはテスト中（-proposedポケット）の状態であり、16.04・18.04・20.04はパッチ未提供のままだ（Cryptika Cybersecurity）。バージョン管理と設定管理が曖昧なままでは、パッチが出ても「どのサーバーに当てるか」の判断が遅れる。

加えて、Go 1.24以降はLinuxのTCPリスナーがデフォルトでMPTCPを有効化するため、担当者が意識せずにMPTCP有効状態のサービスを運用しているケースが発生しやすい（BleepingComputer）。「設定した覚えがないのに有効になっている」という状態が、見落としを生む典型だ。

Red Hatはこの脆弱性をCVSSスコア5.9と評価し、主にDoS（カーネルクラッシュ）リスクとしている（BleepingComputer）。NVDの9.8との差は珍しくなく、スコア単体で優先度を決めると判断を誤る。自社環境のMPTCP有効化状況・インターネット公開範囲・カーネルバージョンの分布が、優先順位の決め手になる。

次に読む：AIハッキングによる情報漏洩の主な被害は？

AIハッキングで情報漏洩が相次ぐ？日本・世界の主な被害一覧【2026年7〜10月】

AIを使ってLinuxカーネル脆弱性を早期に検知・対応する具体的な方法

未然に防ぐ：資産管理とリスクスコアリングの自動化

脆弱性対応で最も時間を食うのが「影響を受ける資産の特定」だ。ここにAIを組み合わせると作業の質が変わる。

SBOM（ソフトウェア部品表）やCMDB（構成管理データベース）と連携したAI分類モデルを使い、カーネルバージョン・MPTCP設定・インターネット公開状況を自動収集・分類する構成が現実的だ。CVE-2026-98432のようにカーネルバージョンと特定設定の組み合わせで影響が変わる脆弱性では、設定レベルまで掘り下げた分類が不可欠になる。

さらに、NVDやベンダーアドバイザリのデータをリアルタイムで取得し、自社資産リストと照合するNLP（自然言語処理）パイプラインを構築すると、「この脆弱性は自社に刺さるか」の判断を自動化できる。機械的なCVSSスコアだけでなく、EPSS（Exploit Prediction Scoring System）など悪用確率を加味した優先順位付けもAIと組み合わせやすい。

早く見つける：異常通信のAI検知

今回観測されたのは、MPTCPを用いた通常とは異なるスキャン手法だ。住宅用プロキシやVPNを経由した分散スキャンは、IPレピュテーションベースのルールだけでは見落としやすい。

機械学習ベースのネットワーク異常検知（Network Traffic Analysis）は、通常のTCPハンドシェイクとMPTCP固有のサブフロー確立シグネチャの差異を学習し、スキャン的な接続パターンを統計的に検出する。ベースラインとなる「正常な通信」をモデルが学習することで、ルールに記載のない新しいスキャン手法も検出対象に入れられる点が従来のシグネチャ型と大きく異なる。

SIEMと連携したAIベースのUEBA（ユーザー・エンティティ挙動分析）では、特定ポートへの短時間集中接続や地理的に分散した同一パターンのアクセスをリアルタイムでスコアリングし、担当者にアラートを上げる構成が一般的だ。

被害を小さくする：パッチ適用の優先順位付けと緩和策の自動提案

パッチが出そろっていない段階では、緩和策の選択と実行速度が被害を左右する。CVE-2026-98432の場合、sysctl経由でのMPTCP無効化やファイアウォールルールによる通信遮断が緩和策として挙げられている（Cryptika Cybersecurityのソース投稿）。

AIを使ったリスクベースのパッチ管理ツールは、各サーバーの重要度・公開状況・MPTCP有効化の有無を組み合わせ、「今すぐ緩和策を適用すべきサーバー」と「次のメンテナンスウィンドウで対応可能なサーバー」を自動で分類する。LLMをバックエンドに持つツールでは、設定変更コマンドの候補をディストリビューションのバージョン別に生成する機能を持つものも出てきている。ただし自動生成されたコマンドを本番環境に直接適用するのはリスクが高く、担当者が内容を確認したうえで実行するフローの維持が前提だ。

図：CVE-2026-98432への対応をAIで支援する4段階フロー。①資産の自動分類から④パッチ優先順位付けまでをAIが候補提示し、最終判断と実行は担当者が担う。

この対応で特に恩恵が大きい組織・場面

対象	現場の課題	AIが補える点
中規模企業のIT担当（少人数）	管理対象サーバーが多く、カーネルバージョンの一覧すら手動管理	資産スキャンとCVEマッチングを自動化し、影響サーバーを即座にリストアップ
自治体・公共機関	レガシーOS（Ubuntu 18.04等パッチ未提供）が残存	EOSサーバーの特定とネットワーク分離・MPTCP無効化などの緩和策を優先提示
クラウドインフラ運用チーム	Go 1.24以降のランタイムでMPTCPが暗黙的に有効化されているサービスを把握できていない	デプロイ済みコンテナイメージのGoバージョンとカーネル設定を横断スキャンし、暗黙MPTCP有効サービスを洗い出す
SOC・セキュリティ監視チーム	分散スキャンをIPレピュテーションのみで検出しきれない	通信パターンの統計的異常をML検知し、住宅用プロキシ経由のスキャンにも感度を持たせる

AIを過信しないために：現場が押さえるべき限界と注意点

AIを脆弱性対応に組み込む際には、いくつかの構造的な限界を認識しておく必要がある。

誤検知と見落としは必ず発生する。異常通信の検知モデルは通常通信のベースラインから学習する。業務上の正当な異常通信（バッチ処理・大規模デプロイ）をアラートとして上げることもあるし、逆に正常通信に偽装した巧妙なスキャンを見逃すリスクもある。最終的な判断は担当者が行うという運用フローを省略してはならない。

監視の強化は個人情報・プライバシーリスクと表裏一体だ。通信ログの詳細収集・分析は、業務利用の内容や個人の行動履歴を含む。収集範囲・保存期間・アクセス権限について、社内ポリシーと個人情報保護法の範囲内で設計する必要がある。

AIが提案する設定変更コマンドは、そのまま本番投入しない。LLMが生成するsysctlコマンドやiptablesルールは、カーネルバージョンやディストリビューション固有の差異を考慮していない場合がある。ステージング環境での検証を省略するコストより、本番障害のコストの方が大きい。

CVSSスコアは絶対的な優先順位基準ではない。Red HatとNVDのスコア差（5.9対9.8）が示すとおり、同一の脆弱性でも評価は異なる。自社環境にMPTCPが有効か否か、インターネットに直接公開されているか否かという文脈依存の情報をAIツールに正確に入力できるかどうかが、スコアリング精度を左右する。

AIツール自体のサプライチェーンリスクも存在する。脆弱性スキャナや異常検知ツールも、外部依存ライブラリやクラウドAPIを通じて攻撃者の標的になりうる。セキュリティツールのアップデートと整合性検証は、業務系ソフトウェアと同等以上の厳格さで管理する必要がある。

明日から試せる実務的な一歩

大規模なAI導入よりも先に、現場で即日実行できる確認作業がある。

まず、管理下のLinuxサーバー全台で次の2点を確認する。①カーネルバージョンがv4.4以降であるか（uname -rで確認）、②MPTCPが有効になっているか（sysctl net.mptcp.enabledで確認）。これだけで対象範囲が絞れる。

次に、Ubuntuを運用している場合はUbuntu Security Notices（USN）のRSSフィードをSOCツールまたはSlack等に連携する。CVE公開からパッチリリースまでの時間差を人手でカバーするうえで最も低コストな仕組みだ。Ubuntuが26.10（Stonking）以外のバージョンを運用している場合は、パッチ提供状況を随時確認し、パッチ未提供の16.04・18.04・20.04環境ではMPTCPの無効化を検討する。

AIツールの導入を検討する段階では、まず自社のCMDBかスプレッドシートベースの資産台帳をCSV出力できる状態にしておくことが前提になる。AIを使った優先度スコアリングは、資産の正確な一覧がなければ精度を出せない。ツール選定より先に資産管理の土台を整える順番が、現場では重要だ。

参考文献

Cryptika Cybersecurity https://www.cryptika.com/attackers-started-scanning-in-the-wild-for-linux-kernel-rce-flaw-ubuntu-releases-fixes/
x.com https://x.com/i/trending/2118046929661952183