CVE-2026-99999（PwnEscape）の影響範囲 ― Docker・AWS ECS（Fargate／EC2）・KVMで自社は対象か

2026年10月15日、LinuxカーネルにCVE-2026-99999という脆弱性が公開されました。発見者が付けた呼び名は「PwnEscape」です。仮想マシン（VM）の中から特殊なネットワークパケットを送ると、外側のホストのメモリを読み出したり、ホストを落としたりできる。研究者の検証環境では、ホストのroot権限でプログラムを動かすところまで確認されています。

「VMエスケープ」「CVSS 9.3」という言葉が並ぶので、まず気になるのは自社の環境が当てはまるかどうかでしょう。DockerでWebアプリを動かしている、AWSのECSでコンテナを運用している、という方が特に多いはずです。この記事では、構成ごとに「影響を受けるか」「何をすればよいか」を判定できるよう、公開されている一次情報を整理しました。

構成別の影響早見表

先に一覧を置きます。判定の根拠は、このあと構成ごとに説明します。

← 表は横にスクロールできます →

CVE-2026-99999（PwnEscape）とは

PwnEscapeは、Linuxカーネルのネットワーク処理（IPv4）にある不具合です。名前に「Escape」とありますが、KVMそのもののバグではありません。KVMの下で動くホストのカーネルが、ゲストから渡されたパケットを処理するときの不具合です。

何が起きるのか

VMの仮想NIC（virtio-net）は、パケットと一緒に「チェックサムの計算はそちらでお願いします。書き込む場所はここです」という情報をホストに渡せます。チェックサムオフロードと呼ばれる仕組みで、ゲストの処理を軽くするためのものです。

ホストのカーネルは、この「書き込む場所」をIPv4ヘッダーと突き合わせて確かめていませんでした。そのため、細工した値を渡すと、カーネルがすでに読んで判断に使ったIPv4ヘッダーの上に、あとからチェックサムが書き込まれます。研究者の例では、ヘッダー長の値が5（20バイト）から15（60バイト）に書き換わり、ホストのフラグメント処理がパケットの外側にある40バイトをヘッダーとして扱いました。そのうち32バイトはホストのメモリで、外に送り出されるパケットに混ざります。

かなり雑に言うと、「確認済みの書類に、あとから他人が書き足せた」という不具合です。研究者はここから、次の3つを示しました。

• ホストのカーネルメモリの読み出し（パケットを送るたびに繰り返せる）
• ホストのクラッシュ（そのホスト上のVMがすべて止まる）
• ホストのカーネルメモリへの書き込みと、ホストのroot権限での実行（研究者自身のKVMとFirecrackerの環境で確認）

メモリの読み出しは、Vercelの本番サンドボックスでも確認されたと報告されています。root権限での実行は研究者の検証環境での結果で、公開時点では実際の攻撃に使われたという報告は見当たりません。ただし研究者は、条件の緩い構成向けの攻撃コードは数週間で出てくるだろうと書いています。

深刻度と経緯

← 表は横にスクロールできます →

上流の修正は、チェックサムを書き込む前に「書き込み位置がIPv4ヘッダーより後ろか」を確かめるものです。修正の説明文では「多層防御のための対処」とされ、入口でのより完全な検証は引き続き作業中とされています。一度更新して終わりではなく、続報が出る前提で見ておくのがよさそうです。

Dockerは影響を受けるか

いちばん多い疑問だと思うので、詳しく書きます。短く答えると、Dockerのコンテナは「VMエスケープ」の対象ではありません。ただし、コンテナを動かしているホストのカーネルは更新対象です。

DockerはVMではない

Dockerはコンテナ型の仕組みで、KVMのような仮想マシンには分類されません。違いは次のとおりです。

← 表は横にスクロールできます →

今回の攻撃は「ゲストVMのカーネルを乗っ取った攻撃者が、virtio-net経由でホストを攻撃する」という形です。通常のDockerコンテナは仮想NICとしてvirtio-netを使わず、ゲスト用の別カーネルもありません。そのため、公式資料が示すVMエスケープの経路は、Dockerにはそのまま当てはまりません。

それでもホストの更新が必要な理由

Red Hatは、悪用できる攻撃者として「信頼できないゲストVM」と並べて「ローカルの攻撃者」を挙げています。AlmaLinuxも、VMを動かしているかどうかに関係なく、すべてのシステムの更新を勧めています。上流の修正が原因として挙げた2つの変更のうち1つは、パケットソケット（AF_PACKET）のチェックサムオフロード対応で、VMを使わずにtunやAF_PACKETから同じ処理に入る筋道も、修正の議論の中で検討されていました。

Dockerのコンテナはホストのカーネルを共有しています。コンテナの中から届くのは、ホストのカーネルそのものです。現時点で、Dockerコンテナから悪用する手順は公表されていません。それでも、コンテナが乗っ取られたときにホストのカーネルの不具合へ手が届く構造なので、コンテナホストは更新の優先度を上げておくべきだと筆者は判断します。

優先度を上げるべきコンテナの条件

パケットを生の形で組み立てて送るには、Linuxの権限（ケーパビリティ）が必要です。次に当てはまるコンテナがあるホストは、先に更新してください。

• --privileged で動かしている特権コンテナ
• NET_ADMIN を付け、/dev/net/tun を渡しているコンテナ（VPNクライアントやTailscale、WireGuardのユーザー空間実装など）
• NET_RAW を持つコンテナ。Dockerは既定で NET_RAW を付けるため、外していなければ当てはまる
• 他人が書いたコードや、ユーザーが投稿したコードを実行するコンテナ（CIランナー、オンラインのコード実行環境、AIエージェントのサンドボックスなど）

ホストで次のように確かめられます。CapAdd と Privileged と Devices を見ます。

# 動いているコンテナの特権・追加権限・デバイスを一覧する
docker ps -q | xargs docker inspect \
  --format '{{.Name}} privileged={{.HostConfig.Privileged}} add={{.HostConfig.CapAdd}} drop={{.HostConfig.CapDrop}} devices={{.HostConfig.Devices}}'

# ホストのカーネルのバージョン
uname -r

不要な権限を外すのは、今回に限らず効く守りです。ping を使わないアプリなら --cap-drop NET_RAW（Composeなら cap_drop: [NET_RAW]）で外せます。ただしこれは攻撃の入口を減らす一般的な対策で、今回の脆弱性の公式な回避策ではありません。本命はホストのカーネル更新です。

Docker Desktop（Mac／Windows）の場合

Docker DesktopはMacやWindowsの上に小さなLinuxのVMを作り、その中でコンテナを動かします。このVMの外側はmacOSやWindowsで、Linuxカーネルのホストではありません。仕組みから考えると、今回のゲストからホストへの脱出の筋道は当てはまりにくい構成です。中のLinux VMのカーネルはDocker Desktopの更新で入れ替わるので、Docker Desktopを最新に保っておけば足ります。

AWS ECS Fargateは対応不要

AWSは2026年10月15日、セキュリティ速報「2026-137-AWS」を出しました。該当部分をそのまま引きます。

AWS-managed compute and container services, including Amazon EC2 instances, AWS Lambda, and AWS Fargate, are not affected. There is no action required for customers using these services.

Amazon EC2、AWS Lambda、AWS Fargateを含む、AWSが管理するコンピューティングとコンテナのサービスは影響を受けず、利用者の対応は不要、という内容です。ECSのFargate起動タイプも、EKSのFargateも、ここに含まれます。

Fargateでは、タスクのコンテナを動かす下の基盤（ホストのOSや仮想化の層）をAWSが管理しています。利用者はそこに手を出せない代わりに、パッチを当てる責任もAWS側にあります。コンテナイメージの中身（アプリやライブラリ）は利用者の管理ですが、今回の脆弱性はカーネルの不具合なので、イメージを作り直す必要はありません。

ECS on EC2・EKSのEC2ノードはカーネル更新を

ここは誤解しやすいところです。AWSの速報は「Amazon EC2は影響を受けない」としています。これはEC2の下にある基盤（ハイパーバイザー側）の話です。EC2インスタンスの中で動いているOSのカーネルは、共有責任モデルでは利用者の管理範囲に入ります。

ECSをEC2起動タイプで使う場合、そのインスタンスは何十ものコンテナを載せるLinuxホストです。前の節のDockerホストと同じ理由で、カーネルの更新を通常より前倒しで計画することをおすすめします。Amazon Linuxにはすでに修正版が出ています。

← 表は横にスクロールできます →

ECSのコンテナインスタンスを更新する

やり方は2つあります。インスタンスを残したまま中のカーネルを上げる方法と、修正版を含むAMIで作り直す方法です。Auto Scalingグループで運用しているなら、作り直すほうが手戻りが少ないでしょう。

# 現在のカーネルを確認する（上の表のバージョン以上か）
uname -r

# Amazon Linux 2023: 最新リリースに上げて再起動
sudo dnf upgrade --releasever=latest
sudo reboot

# Amazon Linux 2: カーネルを更新して再起動
sudo yum update kernel
sudo reboot

# 最新のECS最適化AMI（Amazon Linux 2023）のIDを調べる
aws ssm get-parameters \
  --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id \
  --query 'Parameters[0].Value' --output text

再起動の前に、ECSのコンテナインスタンスを「DRAINING」にしてタスクを別のインスタンスへ逃がします。作り直す場合は、起動テンプレートのAMIを新しいものに替えて、Auto Scalingグループのインスタンスの更新（インスタンスリフレッシュ）を使います。新しいAMIに替えたら、起動したインスタンスで uname -r を実行し、表のバージョン以上になっているかを必ず確かめてください。AMIの公開日だけでは、修正版のカーネルが入っているかはわかりません。

BottlerocketやUbuntuなど、Amazon Linux以外のAMIを使っている場合は、それぞれの告知で修正版を確認します。EKSのマネージドノードグループも、考え方は同じです。

タスク定義の権限も見直す

EC2起動タイプのタスク定義では、privileged や linuxParameters.capabilities で権限を足せます。どのタスクに付いているかは次のように確かめられます。

aws ecs describe-task-definition --task-definition <タスク定義名> \
  --query 'taskDefinition.containerDefinitions[].{name:name,privileged:privileged,caps:linuxParameters.capabilities}'

特権や NET_ADMIN を付けたタスクが載っているクラスターから、先に更新します。

EC2で仮想マシンを動かしている場合

ベアメタルインスタンス（*.metal）やネストした仮想化で、EC2の上にKVMやFirecrackerを載せている場合は話が変わります。AWSの速報が「影響を受ける製品」として挙げているのは、まさに「virtio-netとKVMで仮想マシンを自分で管理している利用者」で、Firecrackerも名指しされています。この場合は次の節の「最優先」に当たります。

KVM・Firecrackerのホストを運用している場合（最優先）

影響がいちばん大きいのは、他人のVMを動かしているLinuxホストです。VPSやクラウドの事業者、社内のプライベートクラウド、コードを実行させるサンドボックスのサービスが当たります。ゲストのVMを1台乗っ取られると、そこからホストを経由して、同じホストのほかのVMにも手が届く可能性があります。

• KVM／QEMU＋virtio-netの環境（libvirt、Proxmox VE、OpenStack、oVirtなど）
• FirecrackerやCloud HypervisorのようなマイクロVM
• Kata ContainersなどのVM型コンテナランタイム（コンテナごとに軽いVMを立てるため、ホストはKVMの構成になる）

対応はホストのカーネル更新と再起動です。再起動すると載っているVMがすべて止まるので、ライブマイグレーションで逃がすか、停止の時間を取ります。社内向けで、ゲストVMを使うのが自社の管理者だけなら、緊急度は少し下がります。それでも、ゲストが乗っ取られたときの被害がホスト全体に広がる構造は同じです。

ベアメタル・普通のLinuxサーバーの場合

物理サーバーやVMの上で、OSに直接アプリを載せて動かしている構成です。ゲストVMがないので、VMエスケープは起きません。

ただし、Red Hatが挙げる「ローカルの攻撃者」の経路は残ります。ネットワークスタックの不具合なので、細工したパケットでOSが落ちる可能性も、完全には否定できません。緊急度は下がりますが、次のパッチ適用の機会にカーネルを更新して再起動してください。複数の人がログインして使うサーバーや、他人のコードを動かすサーバーは前倒しにします。

VPS・クラウドのVMを借りている場合

VPSやクラウドのVMを借りている側から見ると、守るべきホストは事業者の持ち物です。ほかの利用者のVMからホストが攻撃されると、自分のVMにも影響が及ぶおそれがあります。利用している事業者が今回の件で告知を出しているか、ホストの更新に伴うメンテナンスの予定があるかを確認してください。自分のVMのカーネルは、前の節と同じく通常の更新で上げておきます。

ディストリビューション別の修正状況

2026年10月17日に各社のページを確認した時点の状況です。

← 表は横にスクロールできます →

AlmaLinuxのテスト用リポジトリは、本番機では有効にしたままにしないよう、AlmaLinux自身が注意しています。RHELやUbuntuのように修正版がまだ出ていない場合、カーネルの更新以外に公式の回避策はないため、出た時点ですぐ当てられるよう、再起動の段取りだけ先に決めておくのが現実的です。

自分の環境を確認する手順

判定の順番をまとめます。

1. ワークロードがどこで動いているかを洗い出す（Fargate、Lambda、EC2、オンプレミス、VPS）
2. Fargate・Lambdaだけなら対応は不要。AWSの速報を記録に残して終わり
3. EC2やオンプレミスのLinuxは、uname -r でカーネルのバージョンを確かめ、ディストリの修正版と比べる
4. そのホストで、他人のVMを動かしているか（最優先）、コンテナを動かしているか（前倒し）を確かめる
5. コンテナホストでは、特権・NET_ADMIN・NET_RAW を持つコンテナを洗い出し、不要なら外す
6. カーネルを更新し、再起動したあとで uname -r をもう一度見て、新しいカーネルで起動したことを確かめる

最後の確認を忘れがちです。パッケージを更新しても、再起動するまでは古いカーネルのまま動いています。

よくある質問

Q. Dockerを使っているだけで影響を受けますか？

公式資料が示す攻撃経路はVMのゲストからホストへの脱出で、Dockerコンテナからの悪用手順は公表されていません。ただし脆弱なコードはVMを動かしていないLinuxにも入っていて、Red Hatはローカルの攻撃者も悪用できるとしています。コンテナを動かすホストのカーネルは更新してください。

Q. AWS ECS Fargateを使っています。対応は必要ですか？

不要です。AWSの速報2026-137-AWSが、Fargateは影響を受けず対応不要と明記しています。

Q. ECSをEC2起動タイプで使っています。対応は必要ですか？

EC2の基盤側はAWSが対応済みです。インスタンスの中のカーネルは利用者の管理なので、Amazon Linuxの修正版カーネルへの更新か、AMIの入れ替えを計画してください。

Q. AWS Lambdaは？

対応不要です。Fargateと同じく、AWSの速報で影響なしとされています。

Q. 回避策はありますか？

AWS、Red Hat、AlmaLinuxとも、カーネルを修正版に更新する以外の回避策はないとしています。

Q. カーネルを更新したら再起動は必要ですか？

必要です。再起動するまでは古いカーネルのまま動いています。

参考資料

• AWS Security Bulletin 2026-137-AWS: Issue in the Linux kernel virtio-net/TAP networking path affecting KVM-based hypervisors（2026-10-15）
• Amazon Linux Security Center: CVE-2026-99999
• Red Hat: CVE-2026-99999
• AlmaLinux: PwnEscape (CVE-2026-99999): Patched kernels available in testing（2026-10-16）
• Debian Security Tracker: CVE-2026-99999
• Ubuntu: CVE-2026-99999
• CVE Record: CVE-2026-99999
• Linux kernel commit 6785011f8b16: ipv4: validate checksum_start before completing checksum
• PWNAI Research: PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999)
• Vercel: Findings from the $1 million Vercel Sandbox challenge