アイキャッチはAI生成の概念イラストです。実際の攻撃画面や機器写真ではありません。
2026年10月15日、Linuxカーネルのネットワーク処理に重大な脆弱性「CVE-2026-99999」が公開されました。通称は「PwnEscape（プウンエスケープ）」です。LinuxカーネルCVEチームの告知では、CVSS v3.1で9.3、深刻度はCriticalと評価されています（Linuxカーネル CVE告知）。
まず、自分の立場で何をすべきかを整理します。
- Amazon EC2、AWS Lambda、AWS FargateなどAWSが管理する基盤の利用者は、このCVEへの対応は不要です。
- virtio-netとKVMを使って仮想化ホストを自主管理している場合は、自分の環境が影響を受ける構成かを確認し、OSベンダーが提供する修正を適用してください。
- さくらのクラウド・VPSの利用者は、受付制限の内容と、今後の個別メンテナンス通知を確認してください。
ただし、これらは各事業者が公表した範囲の説明です。AWSの説明は管理基盤に関するものであり、AWS利用者のアプリケーション全体の安全を保証するものではありません。
特徴は、仮想マシン（VM）の内部から、本来触れられないホスト側のメモリを読んだり、ホストに影響を与えたりする経路になり得る点です。国内ではさくらインターネットが一部サービスの受付を一時停止し、AWSは管理基盤について影響がないと説明しています。同じLinuxの脆弱性でも対応が分かれる理由を、順に整理します。
PwnEscapeとは？ 仮想マシンの境界を越える脆弱性
クラウドでは、1台の物理ホスト上で複数のVMが動きます。各VMではゲストOSのカーネルが動いていますが、仮想NICを介した通信にはホスト側のネットワーク処理との接点があります。PwnEscapeは、この隔離の境界を越え得る脆弱性です。
発見者Paulos Yibelo氏らは、Vercelが実施した100万ドル規模の研究チャレンジを機に、Linuxカーネルのネットワーク処理に問題を見つけました。重要なのは、KVM本体ではなく、ホストLinuxのネットワーク処理に原因があった点です（詳しくはpwn.aiの技術解説）。
原因は「チェックサム」と処理の順序
通信では、データの破損を検出するために「チェックサム」を使います。Linuxは性能のため、チェックサム計算を後回しにしたり、ネットワーク機器に任せたりします。このとき、どこに書き込むかを示す位置情報を管理しています。
今回の問題は、不正なチェックサム情報を持つパケットが処理されると、skb_checksum_help()によって、すでに検証済みだったIPv4ヘッダーの一部が後から書き換わり得ることにありました（詳しい仕組みはpwn.aiの技術解説）。IPv4ヘッダーは宛先や構造を記録する部分で、例えるなら配送伝票の内容を一度確認した後に、別作業で伝票自体が書き換わるようなものです。後続処理は書き換わった情報を信頼して動くため、本来参照すべきでない領域を扱う問題につながります。
どこまで実証されているのか
報告の内容と実証範囲は分けて理解する必要があります。Vercelの公式発表によると、ホストメモリの漏えいは同社の本番サンドボックスで実証されました。一方、ホストのクラッシュとホスト権限でのコード実行は、研究者自身のKVMおよびFirecracker環境で示されたものです（Vercelの発表）。
Vercelは、顧客のファイルやシークレット、アプリケーションデータへのアクセスを示す報告はなかったと説明しています。ただしこれは同社環境に関する説明であり、世界全体で被害がゼロだったと断定するものではありません。
また、この脆弱性は、インターネットから通常のパケットを送るだけで全てのLinuxが侵害される、という性質のものではありません。AWSは、ゲスト内で特権的なアクセスを持つことが条件になると説明しています。権限条件を一般化して捉えないよう注意したいです。
なお、Vercelの10月14日の記事の時点ではCVEが審査中とされていました。CVE番号と修正版は、10月15日のLinuxカーネル公式告知で確認できます。
AWSのEC2などは影響を受ける？
AWSは2026年10月15日のセキュリティ速報で、Amazon EC2、AWS Lambda、AWS Fargateは影響を受けず、利用者に対応は不要と説明しています（AWS Security Bulletin 2026-137-AWS）。
ただし、利用者自身がvirtio-netとKVMを使って仮想化ホストを構築・管理している場合は別です。影響を受ける構成で、まだ未修正である場合に限り、自分で管理するLinuxホストのカーネルを更新してください。再起動はベンダーの案内に従います。AWSはAmazon Linux向けの修正済みカーネルパッケージを提供しています。「AWSが管理する基盤」と「自分で管理するホスト」を分けて考えるのが要点です。
さくらのクラウド・VPSの対応
国内では、さくらインターネットが受付の制限を行っています。さくらのクラウドは、10月16日から新規プロジェクトの作成を一時停止しました。この受付停止に伴う、作成済みプロジェクトのリソースの稼働への影響はないと案内されています（さくらのクラウドの案内）。
さくらのVPSでは、石狩・東京・大阪の全リージョンで新規申し込みを一時停止し、スケールアップ、持ち込みISOのインストール、さくらのクラウドへの移行も停止しています。契約済みプランは通常どおり稼働し、再開時期は未定です。ホストメンテナンスを含む対応を実施する可能性も示されています（さくらのVPSの案内）。さくらインターネットは、さくらのクラウド、VPS、レンタルサーバなど対象サービス全体の影響調査を進めていると説明しています（さくらインターネットのお知らせ）。
なお、受付制限の告知だけで、情報漏えいの有無や対策完了を判断することはできません。各社の続報を待つ必要があります。
Linuxサーバー管理者が確認すべきこと
LinuxカーネルCVEチームの告知では、修正を含むバージョンが示されています。ただしUbuntuやRed Hat Enterprise Linux、Amazon Linuxなどは修正を独自にバックポートすることがあります。Red Hatは暫定評価としてCVSS v3で8.8を示しており、深刻度の評価はベンダーごとに異なる点も押さえておきたいです（Red HatのCVE情報）。上流の版番号だけでディストリビューションの安全性を判断してはいけません。
手順は、まず自分のOSベンダーが該当CVEの修正パッケージを出しているか照合します。次に、自分の仮想化ホストが影響を受ける構成であれば更新し、再起動はベンダーの案内に従います。最後に稼働中のカーネルを再確認します。
uname -rは現在実行中のカーネルを表示し、cat /etc/os-releaseはOSの情報を示します。ただしVMの内部でuname -rを実行しても、クラウド事業者が管理するホストのカーネルは確認できません。自分が管理する範囲で照合することが大切です。
AIを活用した研究という側面
発見者のpwn.aiは、ソースコード分析や仮説検討にAIを活用したと明らかにしています。ただし、AIが完全自動で脆弱性を発見し攻撃を完成させたわけではなく、人間が方向を定め、実験・検証・パッチ検討を進めました（pwn.aiの技術解説）。AIが解析を支え、人間が判断を担う研究の姿がうかがえます。
まとめ
PwnEscapeは、ネットワーク処理の小さな不具合が、仮想マシンの隔離を揺るがす問題に発展した例です。仮想マシンはホストから独立して見えますが、仮想NICやネットワーク処理など、ゲストとホストの接点は数多くあります。
だからこそ、クラウドだから安全、仮想マシンだから安全と決めつけず、自分の利用環境の責任範囲を把握することが大切です。
（ベア三郎）VM内のOS更新と、事業者が管理するホストの対策は別に行われます。自分の責任範囲を把握することが重要だと感じました。
本記事は2026年10月17日時点の公開情報に基づきます。影響範囲や修正状況、各社の対応は変わり得るため、最新の一次情報をご確認ください。
コメント