Linuxカーネルのネットワーク処理に関する脆弱性CVE-2026-99999（通称「PwnEscape」）が2026年10月15日に公開された。細工したネットワークパケットとチェックサム・メタデータを扱えるローカル攻撃者や信頼できない仮想マシンから、ホストカーネルのメモリ破壊、情報漏えい、サービス停止、条件次第では任意コード実行につながる。

さくらインターネットは10月16日、さくらのクラウド、さくらのVPS、さくらのレンタルサーバ、高火力DOK、高火力VRTなどを対象に影響調査と対応を進めていると案内した。複数サービスで新規申し込みや一部機能が停止しているが、公開情報の範囲では既存リソースは通常どおり稼働している。利用者が今すべきことは、一律の停止ではなく、誰がホストOSを管理しているかを確認し、自分の責任範囲を更新できる状態にすることである。

この脆弱性が「ホスト脱出」と呼ばれる理由

仮想マシンはCPUやメモリだけでなく、仮想NICを通じてホストのネットワーク処理とも接する。CVE-2026-99999では、ゲスト側が指定した不正なチェックサム位置情報がホスト側LinuxのIPv4処理へ入り、いったん検証したヘッダを後から書き換え得る。研究チームは自己所有のKVM環境で、ホストメモリの読み出し、選択的書き込み、ホストroot権限での実行までを実証した。

「仮想化ソフトの外へ出る」という結果だけを見ればKVMの脆弱性に見えるが、根本原因はLinuxカーネルのネットワークスタックにある。そのため、KVM以外でも同じLinuxネットワーク経路へ信頼できない入力を渡す構成は評価が必要になる。一方、研究室で成立した完全な攻撃チェーンが、すべてのクラウド製品・ネットワーク構成で同じ難易度で成立するという意味ではない。

深刻度の数字が一致しないのはなぜか

Red HatはCritical、CVSS 3.1で8.8と評価している。UbuntuのページはCVSS 9.3を掲げる一方、Ubuntuとしての優先度はMediumとしている。矛盾ではない。CVSSは想定した攻撃条件と技術的影響を一定の形式で表す指標であり、ベンダーの優先度は製品構成、既定設定、攻撃面、配布状況を加味した判断だからだ。

運用者は数字の大小だけで並べず、次の3点を確認する。

  1. 信頼できないゲスト、ローカルユーザー、特権コンテナが存在するか。
  2. その主体がvirtio-net、TAP/TUN、packet socketなど問題のある経路へ入力できるか。
  3. ホストカーネルの更新と再起動を誰が実施する契約・構成か。

さくらのサービス別に責任分界を整理する

利用形態ホスト側の主な対応者利用者が今確認すること
さくらのクラウド基盤ホストはさくらインターネット個別案内、メンテナンス予定、ゲストOSの更新、再起動後の動作確認
さくらのVPS物理ホストはさくらインターネット事業者の対応状況と、自分が管理するVPS内カーネルのベンダー勧告
レンタルサーバ／マネージドサーバサービス側の管理範囲が大きい公式のお知らせを追い、利用中アプリのバックアップとメンテナンス影響に備える
専用サーバPHYなどOSを自分で管理するサービス利用者OSベンダーのCVE判定、カーネル更新、再起動、仮想化・コンテナ構成の棚卸し
専用サーバ上で自営KVM／Firecracker利用者ホストカーネルを最優先で更新。信頼できないゲストを新規に受け入れない

クラウドやVPSの利用者が、物理ホストのカーネル状態をゲストから直接確認することはできない。逆に、事業者が物理ホストを修正しても、利用者が自分で導入したゲストOSや入れ子の仮想化環境まで自動的に修正されるとは限らない。双方の対応が必要になり得る。

さくらインターネットの停止措置をどう解釈するか

10月16日のサービス別案内では、さくらのクラウドが新規プロジェクト作成を停止し、さくらのVPSが全リージョンの新規申し込み、スケールアップ、持ち込みISOのインストール、クラウドへのマイグレーションを停止した。レンタルサーバとマネージドサーバも新規申し込みを停止している。既存リソースは通常どおり稼働すると説明されている。

これは侵害発生の公表ではなく、調査・対策中に新たな配置や状態変更を増やさないための予防的な運用措置と考えられる。少なくとも公開された一次情報は、ベンダー本番環境での侵害を主張していない。ただし、今後ホストメンテナンスが実施される可能性は明記されているため、無停止を前提にしたまま待つのは危険である。

優先度を4段階で決める

優先度該当例対応
緊急自営KVM／Firecrackerで第三者やテナントのゲストを実行新規ゲストを止め、ホスト修正・退避・再起動を最優先
高CIサンドボックス、検証基盤、ホスティングなどゲスト管理者を十分に信頼できない資産と信頼境界を確定し、ベンダー修正版が届き次第メンテナンス
中単一組織のVM基盤だが、複数管理者や特権ワークロードがある通常の緊急パッチ手順へ載せ、権限とTUN/TAP利用を見直す
監視事業者管理の共有ホストを使う一般的なクラウド／VPS利用者事業者通知を追い、ゲストOS更新とメンテナンス準備を進める

「監視」は何もしないという意味ではない。利用者側で制御できないホスト修正を事業者へ委ねつつ、自分の責任範囲を先に片付けるという意味である。

今すぐ行うチェックリスト

1. 資産と管理責任を確定する

  • 対象サービス、リージョン、契約ID、サーバ名、重要度、担当者を一覧化する。
  • 物理ホスト、ゲストOS、コンテナノードのそれぞれを誰が更新するか書き分ける。
  • 入れ子の仮想化、自営KVM、Firecracker、CIサンドボックスの有無を確認する。
  • 特権コンテナ、CAP_NET_ADMIN、/dev/net/tunの付与を棚卸しする。

2. 変更前の復旧手段を確認する

  • 重要データのバックアップが直近に成功しているか確認する。
  • スナップショットだけに依存せず、別障害ドメインに復旧可能なコピーを持つ。
  • 再起動後に起動しない場合のコンソール接続、レスキューモード、旧カーネル起動手順を確認する。
  • ロードバランサや冗長構成があるなら、1台ずつ退避・更新・復帰できる順序を決める。

3. カーネルを更新し、実行中の版を確認する

uname -r
uname -v
cat /etc/os-release

修正版の有無はOSベンダーのCVEページで判定する。ディストリビューションは修正を古いカーネル版へバックポートするため、上流のバージョン番号だけで脆弱・安全を決めない。更新パッケージをインストールした後も、再起動前は古いカーネルが動き続ける。再起動後に再度uname -rを取り、変更記録へ残す。

4. 公式通知の受け口を決める

サービスごとのニュース、会員向けメール、メンテナンス・障害情報を担当者が確実に受け取れるようにする。個人の受信箱だけに依存せず、チケットや運用チャネルへ転記する。通知には対象リソース、開始・終了時刻、想定影響、利用者側作業を紐付ける。

パッチ待ちの間にできること

Red Hatは、広く安全に適用できる一般的な緩和策はないとしている。設定変更だけで直ったとみなさず、次の措置を「攻撃面を狭める暫定策」として扱う。

  • 信頼できない新規VMやサンドボックスの起動を停止する。
  • ゲスト管理者権限を必要最小限にし、不要なTUN/TAPや特権コンテナを止める。
  • 修正済みホストへ移せるワークロードは退避する。
  • ホストのカーネルログ、監査ログ、仮想化管理ログを集中保管し、保持期間を延ばす。
  • 変更凍結の例外として緊急カーネル更新を承認できる経路を確保する。

侵害が疑われるときの初動

今回の脆弱性はカーネルメモリへ影響するため、通常のアプリログだけでは痕跡が残らない可能性がある。カーネルパニック、予期しないネットワーク停止、仮想化ホスト上の未知プロセス、権限設定や起動項目の不審な変更が同時期に起きた場合は、単なる障害として再起動だけで済ませない。

  1. 疑わしいホストへの新規ワークロード配置を止める。
  2. 管理プレーンから時刻、対象VM、ホスト、操作履歴を保全する。
  3. journalctl -k、auditログ、libvirt／VMMログ、ネットワーク機器ログを別の安全な場所へ保存する。
  4. 可用性とのバランスを取りながらネットワーク隔離を判断する。
  5. クリーンなホストとイメージへ再展開し、認証情報を交換する。単なるパッチ適用だけで侵害済み状態が消えるとは考えない。

研究報告は自己所有環境での完全なホスト脱出を示したが、ベンダーの本番環境でのコード実行を主張してはいない。アラートの原因をCVE-2026-99999と断定する前に、通常の障害、既知の運用変更、別の侵入経路も並行して調べる。

経営・利用部門へ伝える要点

説明は「CVSSが何点か」より、サービス影響と意思決定に寄せる。

  • Linux仮想化ホストの分離境界に関わる重大な問題が公開された。
  • さくらインターネットは影響調査中で、一部の新規受付・機能を予防的に停止している。
  • 既存サービスは公開情報上は稼働中だが、ホストメンテナンスの可能性がある。
  • 当社側は、管理対象OSの更新、バックアップ確認、再起動計画、公式通知の監視を進めている。
  • 新しい事実が出たときに、対象システムと判断を更新できる記録を残す。

情報源

本記事は2026年10月16日に公開された情報を基にしている。さくらインターネットと各OSベンダーの調査・修正状況は変わり得るため、実際の対応時には最新の公式案内を確認してほしい。