CVE-2026-99999 PwnEscape｜KVM ホストの影響と対応

はじめに

2026 年 10 月 15 日、Linux カーネルの IPv4 ネットワーク処理に関する脆弱性 CVE-2026-99999（通称 PwnEscape）が公開されました。発見者の研究環境では、KVM 上のゲスト VM からホストのメモリ漏えい、ホストのクラッシュ、ホスト権限でのコマンド実行まで実証されています。

一方で、「KVM の脆弱性」「インターネットからパケットを送るだけで侵害される」といった受け止め方は正確ではありません。運用担当者が判断すべきなのは、自社のどの Linux が「ゲストを収容するホスト」なのか、そのホストのディストリビューションで修正が提供されているか、という点です。

結論として、最優先で対応すべきなのは、信頼できないゲスト VM やワークロードを収容している Linux の KVM ホストです。脆弱なコードはホスト側のカーネルにあるため、ゲスト VM 内の Linux を更新してもホストの対策にはなりません。修正の有無は uname -r の上流バージョンではなく、各ディストリビューションの Advisory と修正済みパッケージで判断してください。

本記事の情報は 2026 年 10 月 17 日（日本時間）時点で確認したものです。修正パッケージの提供状況は日々変わるため、作業前に各ベンダーの最新情報を確認してください。

CVE-2026-99999（PwnEscape）とは

CVE-2026-99999 は、チェックサム計算の途中状態を示すメタデータ（csum_start、csum_offset）が不正なパケットを IPv4 処理が受け入れた結果、検証済みの IPv4 ヘッダーが書き換えられる脆弱性です。CWE は CWE-787（範囲外書き込み）に分類されています。

脆弱性の概要

発見者の技術解説によると、脆弱なのは KVM のコードではなく、ホスト側 Linux の IPv4 ネットワーク処理です。upstream の修正（コミット 6785011f8b16）は、チェックサム計算を完了する前に csum_start を検証するガードを追加するもので、CVE の説明でも多層防御としての修正と位置付けられています。入力時点でのより広範な検証は、今後の課題とされています。

ゲスト VM からホストへ影響が生じる仕組み

Linux kernel CNA が CVE Record に記載した攻撃シナリオでは、悪意のあるゲスト（microVM）が virtio-net のチェックサムメタデータを細工したフレームを送信します。VMM（仮想マシンモニター）がそのフレームをホストの TAP デバイスへ書き込むと、ホストの IPv4 処理でフラグメント化の際に skb_checksum_help() が呼ばれ、ホストカーネル内でヘッダーが書き換えられます。

発見者の解説では、この書き換えにより IPv4 ヘッダー長（IHL）が 20 バイトから 60 バイトへ変わり、パケット本来のデータ範囲を超えた 32 バイトのホストメモリが IP オプションとして送信されるとしています。

参考: CVE Record（Linux kernel CNA）
“this is a guest/local virtual-device path, not an Internet receive path.”
（これはゲスト / ローカルの仮想デバイス経路であり、インターネットからの受信経路ではない。）
https://www.cve.org/CVERecord?id=CVE-2026-99999

CVSS の Attack Vector が Local（AV:L）とされているのはこのためです。インターネット上から任意のパケットを送るだけでホストが侵害される脆弱性ではなく、攻撃者はゲスト VM などホストの仮想デバイスへパケットを渡せる位置にいる必要があります。

仮想マシンを使わないローカル攻撃については、Red Hat が「ローカルの攻撃者」も攻撃主体に含めています。発見者の解説でも、TUN や AF_PACKET を使う VM なしのシナリオが当初の議論で検討されたと触れていますが、具体的な条件は公開されていません。

CVSS 8.8 と 9.3 の違い

Red Hat と Linux kernel CNA のスコア差は、主に Privileges Required（攻撃に必要な権限）の評価の違いによるものです。どちらの前提を自社環境に当てはめるかで、優先度の判断が変わります。

CNA はホストから見た権限を基準に、「ゲストの所有者はホストに対して何の権限も持たない」という立場で PR:N としています。一方、Red Hat は攻撃の起点となる環境で一定の権限を要すると評価し、AWS はゲスト内の特権を条件として明記しています。ゲスト内で利用者が root 権限を持てるクラウドやホスティング、サンドボックス基盤では、両者の差は実質的な防御にならない点に注意が必要です。

なお、Red Hat の深刻度表示（Important / Critical）は、確認した時点や参照先によって異なる情報が見られます。公開時点の表示は Red Hat の CVE ページで確認してください。

影響を受ける Linux 環境と修正バージョン

判断の軸は「信頼できないゲストやワークロードからパケットを受け取る Linux ホストか」です。ゲスト OS が Linux かどうかではありません。

仮想化構成ごとの影響判断

Red Hat は OpenShift Container Platform 4 のノード OS（RHCOS）を Affected としています（次節の表を参照）。上表のコンテナ基盤の優先度は、構成上の推論に基づく編集上の提案です。

upstream の修正版と RHEL の修正の違い

CVE Record では、次の stable 系列以降が修正済みとされています。

これらは kernel.org の upstream カーネルのバージョンであり、RHEL などのディストリビューションの修正済みパッケージ番号を意味しません。RHEL はカーネルの修正をバックポートして提供するため、uname -r が示す 5.14.0 などの上流ベースバージョンを上表と比較しても、修正の有無は判定できません。

Red Hat の CVE ページでは、製品別のステータスが次のとおり示されています。

Affected は「影響を受ける」という評価であり、修正パッケージが提供済みであることを意味しません。確認した時点では、いずれの製品にも修正 Errata（RHSA）が掲載されておらず、RHEL と OpenShift に適用できる修正版はまだ提供されていません。Errata が掲載された時点で、本記事の手順に沿って適用を進めてください。

ディストリビューション側で修正版の番号が公表されている例として、AWS は Amazon Linux の修正済みカーネルを次のとおり示しています。

Amazon Linux の番号が upstream の修正版（例: 6.1.190）より小さいのは、修正を独自にバックポートしているためです。ここからも、上流バージョンの比較だけでは判断できないことがわかります。なお、AWS は影響範囲を「パッチ未適用の 4.4 から 6.18 のカーネル」と記載しており、CVE Record の「2.6.27 で混入」とは表現が異なります。古いカーネルを運用している場合も、上流バージョンで対象外と判断せず、ベンダーの情報を確認してください。

CVE-2026-99999 の影響を自社環境で確認する手順

次の順序で確認すると、優先度の高いホストから漏れなく対応できます。コマンドは RHEL 9 の公式ドキュメントに記載されたものです（RHEL 8 の公式ドキュメントでは、同じ操作を yum で記載しています）。

dnf updateinfo list security --installed

oc get nodes -o wide

dnf updateinfo list updates security

dnf updateinfo info <Update ID>

dnf update --advisory=<Update_ID>

dnf update kernel

参照した公式資料は次のとおりです。RHEL 7 と RHEL 10 は、それぞれのバージョンの公式ドキュメントでコマンドを確認してください。

• RHEL 9: Managing, monitoring, and updating the kernel
• RHEL 9: Managing and monitoring security updates
• RHEL 8: Managing and monitoring security updates
• OpenShift Container Platform 4.21: Summarizing cluster specifications
• OpenShift Dedicated 4: Working with nodes

修正版の適用と更新できない場合の対応

本 CVE の根本対策は、修正を含むカーネルへの更新と再起動です。Red Hat と AWS のいずれも、広く推奨できる回避策を示していません。

修正版が未提供の場合の判断

参考: Red Hat Customer Portal（CVE-2026-99999）
“…the currently available options do not meet the Red Hat Product Security criteria”
（……現在利用可能な選択肢は、Red Hat Product Security の基準を満たしていない。）
https://access.redhat.com/security/cve/cve-2026-99999

Red Hat の Mitigation 欄は、緩和策が利用できないか、現在利用可能な選択肢が「導入の容易さ」「幅広い環境への適用性」「安定性」という同社の基準を満たさない、という定型文です。特定の設定変更が「RHEL 全般で有効」と保証されたものではありません。AWS も、セキュリティ速報で回避策はないとしています。

コミュニティでは、仮想 NIC のチェックサムオフロード無効化や、NIC モデルの変更などが議論されています。ただし、いずれも確認した時点で Red Hat や AWS が案内した方法ではなく、脆弱な処理経路を確実に塞げるかは検証されていません。採用する場合は、ゲストの性能や再起動の影響も含めて自環境で評価してください。

修正版が提供されるまでの対応は、根本修正とは異なる運用上のリスク低減策にとどまります。具体的には、信頼できないゲストを収容するホストの特定、信頼できないゲストの新規受け入れ制限、重要なワークロードと信頼できないゲストの配置の見直し、修正版の提供状況の監視などが挙げられます。

ゲスト内の root 権限を制限する案もありますが、確実な緩和策とは言えません。AWS はゲスト内の特権を持つ攻撃者を想定している一方、Linux kernel CNA は割り当てられた virtio-net から送信できるワークロードであれば足りるとして PR:N と評価しており、前提が一致していないためです。あわせて、修正版の提供後すぐに適用できるよう、メンテナンス枠を先に確保しておくことを推奨します。

KVM ホスト更新時の停止計画と更新後の確認

カーネルの切り替えにはホストの再起動が伴うため、収容しているゲストの扱いを事前に決めておく必要があります。具体的な手順は仮想化基盤の製品ごとに異なるため、次の観点で各製品の手順を確認してください。

• ゲストの扱い: ライブマイグレーションで別ホストへ退避できるか、停止が必要か、利用者への事前通知が必要かを決めます。
• 実行中カーネルの切り替え: パッケージの更新だけでは修正は反映されません。再起動後に起動したカーネルを確認します。
• クラスター構成の作業順序: 1 台ずつ退避、更新、復帰を繰り返し、移行先ホストに十分なリソースがあることを確認します。移行先が未更新のホストのみになる時間帯に注意します。
• 切り戻し: 更新後に問題が起きた場合に備え、旧カーネルで起動する方法（RHEL では grubby による既定カーネルの変更など）と判断基準を決めておきます。旧カーネルへ戻すと本 CVE に再び露出するため、切り戻しは障害対応のための一時措置とし、期間と再適用の計画をあわせて決めます。
• 更新後の確認: ゲストの起動、ゲストからの外部疎通、仮想ブリッジや VLAN などホスト側ネットワーク設定の反映を確認します。

直近では、Dirty Frag（CVE-2026-43284）や、RHEL と OpenShift の対応状況も扱った Fragnesia（CVE-2026-46300）など、原因の異なる Linux カーネルの脆弱性も公開されています。ホストの再起動回数を抑えるため、適用予定のカーネルでこれらの修正状況もあわせて確認することをおすすめします。

悪用状況とクラウド事業者の対応

研究者による実証、本番環境での確認、攻撃者による実悪用は、それぞれ別の事実として扱う必要があります。

研究環境と Vercel 本番環境で確認された内容

発見者は、ベンダーの本番環境でホスト root 権限のコマンド実行を実証したとは主張していません。Vercel は、ホストカーネルの更新に加え、ネスト仮想化の無効化や Firecracker の jailer による microVM プロセスの制限といった強化策を実施したとしています。

参考: Vercel
“No reports showed anyone accessing customer data in Vercel Sandbox.”
（Vercel Sandbox の顧客データに誰かがアクセスしたことを示す報告はなかった。）
https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge

公開 PoC と実環境での悪用状況

• 公開 PoC: 発見者は攻撃コードを公開しておらず、ホスト制御までの詳細は続編で扱うとしています。発見者は、数週間から 1 か月程度で公開エクスプロイトが現れる可能性に言及しています。
• CISA KEV: 2026 年 10 月 16 日公開のカタログ（2026.10.16 版）には掲載されていません。
• CISA の評価: CVE Record に付与された CISA の SSVC 評価では、悪用状況（Exploitation）が「none」、技術的影響が「total」とされています。
• 実環境での悪用: 確認できた範囲では、攻撃者による悪用の報告はありません。

悪用報告がないことは、リスクが低いことを意味しません。攻撃手法の詳細が公開される前に、信頼できないゲストを収容するホストの更新を済ませておくことを推奨します。

クラウド事業者の対応と利用者が確認すべきこと

AWS は、Amazon EC2、AWS Lambda、AWS Fargate は影響を受けず、利用者の対応は不要と公表しています。一方で、利用者が virtio-net と KVM（Firecracker などを含む）で VM を自己管理しているホストは影響を受けるとし、Amazon Linux の修正済みカーネルの適用と再起動を求めています。

参考: AWS Security Bulletin 2026-137-AWS
“There are no workarounds for this issue.”
（この問題に対する回避策はない。）
https://aws.amazon.com/security/security-bulletins/2026-137-aws/

AWS の「影響なし」はあくまで AWS のマネージドサービスに対する判断であり、他のクラウド事業者やホスティング事業者にそのまま当てはまるものではありません。国内では、さくらインターネットが 2026 年 10 月 16 日から、さくらのクラウドの新規プロジェクト作成や、さくらの VPS の新規申し込みなどを一時停止し、影響調査を進めています。同社は、必要に応じてホストのメンテナンスを実施し、対象の利用者へ個別に案内するとしています。

クラウドや VPS の利用者は、事業者の公表内容とメンテナンス通知を確認し、自らが KVM ホストを運用している部分（ネスト仮想化やベアメタル上の VM）だけを自社の対応範囲として切り分けてください。

参考: さくらのクラウドにおける対応状況 / さくらの VPS における対応状況 / PWNAI Research の技術解説

まとめ

CVE-2026-99999（PwnEscape）は、ホスト側 Linux カーネルの IPv4 処理に起因し、ゲスト VM からホストへ影響が及ぶ脆弱性です。対応の中心は、信頼できないゲストを収容する KVM ホストの特定と、ディストリビューションが提供する修正済みカーネルへの更新です。

• 脆弱なのは KVM 自体ではなくホスト側の IPv4 処理
• インターネットからの受信だけで侵害される脆弱性ではない
• ゲスト VM 内の Linux を更新してもホストの対策にはならない。
• upstream の修正版番号で RHEL の修正有無は判定できない。
• Red Hat と AWS はいずれも有効な回避策を示していない。
• カーネル更新後は再起動と実行中カーネルの確認が必要
• 確認できた範囲では、実環境での悪用報告はない。

以上、最後までお読みいただきありがとうございました。