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

※この記事は、以下の当方ブログの要約です。全文は以下をどうぞ。

ブログ記事の全文

 30秒の紹介動画

2026年10月15日、Linuxカーネルの脆弱性CVE-2026-99999（通称PwnEscape）が公開されました。CVSSは9.3（cve.org。Red Hatの評価は8.8）。仮想マシンの中から細工したネットワークパケットを送ると、外側のホストのメモリを読み出したり、ホストを停止させたりできるというものです。発見した研究者は、自身の検証環境でホストのroot権限での実行まで確認しています。

「VMエスケープ」という言葉が先行していますが、DockerやAWS ECSを使っている現場で知りたいのは「自社の構成が対象かどうか」だと思います。ここでは一次情報（AWSのセキュリティ速報2026-137-AWS、Red Hat、AlmaLinux、Debian、Ubuntu、研究者の解説）をもとに、構成別に判定します。

結論：構成別の判定

・AWS ECS Fargate、EKS on Fargate、AWS Lambda：対応不要。AWSの速報が「影響なし・対応不要」と明記しています。
・ECS on EC2、EKSのEC2ノード：前倒しで対応。EC2の基盤はAWSが対応済みですが、インスタンスの中のOSのカーネルは利用者の管理です。
・Dockerなどのコンテナを動かすLinuxホスト：前倒しで対応。VMエスケープの直接の対象ではありませんが、カーネル更新の対象です。
・KVM、Firecracker、Kata Containers、Proxmox VE、OpenStackなどで他人のVMを動かすホスト：最優先で対応。
・VMもコンテナも他人に使わせていない普通のLinuxサーバー：通常のパッチ運用で更新。

脆弱性の仕組み

不具合があるのはKVMではなく、ホストのLinuxカーネルのIPv4処理です。VMの仮想NIC（virtio-net）は、パケットと一緒に「チェックサムはそちらで計算し、この位置に書き込んでほしい」という情報（csum_startとcsum_offset）をホストに渡せます。チェックサムオフロードと呼ばれる仕組みです。

ホストはこの書き込み位置をIPv4ヘッダーと突き合わせていませんでした。そのため、細工した値を渡すと、ホストがすでに読んで判断に使ったIPv4ヘッダーの上に、あとからチェックサムが書き込まれます。研究者の例では、IPフラグメント処理の途中でヘッダー長（IHL）が5（20バイト）から15（60バイト）に書き換わり、パケットの論理的な範囲の外にあるホストのメモリ32バイトが、IPオプションとして外へ送り出されました。

影響するコードは、2008年（Linux 2.6.27）のtun/tapのvirtioネットワークヘッダー対応と、2010年のパケットソケットのチェックサムオフロード対応にさかのぼります。AWSの速報はカーネル4.4から6.18を対象と記載しています。

修正はメインラインのコミット6785011f8b16（2026年10月14日取り込み）です。チェックサムを書き込む前に、書き込み位置がIPv4ヘッダーより後ろにあるかを確かめます。上流はこれを多層防御の対処と位置づけており、入口でのより完全な検証は引き続き作業中です。回避策は公表されておらず、修正版カーネルへの更新と再起動だけが対策です。

Dockerはなぜ「対象外」と言い切れないのか

Dockerのコンテナは仮想マシンではありません。仮想NICにvirtio-netを使わず、ゲスト用の別カーネルもないため、公式資料が示す「ゲストVMからホストへ」という経路は、そのままは当てはまりません。

一方で、Red Hatは悪用できる攻撃者として、信頼できないゲストVMと並べて「ローカルの攻撃者」を挙げています（CVSSの攻撃元区分もローカル）。原因となった変更の片方はパケットソケット（AF_PACKET）のチェックサムオフロード対応で、VMを使わずtunやAF_PACKETから同じ処理に入る筋道も、修正の議論で検討されていました。コンテナはホストのカーネルを共有しているので、コンテナが乗っ取られれば、この不具合のあるホストカーネルに手が届く構造です。

現時点で、Dockerコンテナから悪用する手順は公表されていません。それでも、次の条件に当てはまるコンテナがあるホストは、カーネル更新を先に済ませるべきだと考えます。

・privilegedで動かしている特権コンテナ
・NET_ADMINを付け、/dev/net/tunを渡しているコンテナ（VPNクライアントなど）
・NET_RAWを持つコンテナ（Dockerは既定でNET_RAWを付与します）
・CIランナーやコード実行サービスなど、他人のコードを動かすコンテナ

pingを使わないアプリなら、cap_dropでNET_RAWを外せます。ただし、これは攻撃の入口を減らす一般的な対策で、公式の回避策ではありません。本命はホストのカーネル更新です。

AWS ECSでの対応

Fargate起動タイプは対応不要です。AWSの速報には、Amazon EC2、AWS Lambda、AWS Fargateを含むAWS管理のサービスは影響を受けず、利用者の対応は不要と書かれています。コンテナイメージを作り直す必要もありません。

誤解しやすいのはEC2起動タイプです。「EC2は影響なし」はEC2の基盤（ハイパーバイザー側）の話で、インスタンスの中のカーネルは共有責任モデル上、利用者の管理範囲です。Amazon Linuxには修正版が出ています。

・Amazon Linux 2023：kernel-6.1.188-233.385.amzn2023、kernel6.12-6.12.110-135.201.amzn2023、kernel6.18-6.18.51-120.162.amzn2023
・Amazon Linux 2：kernel-4.14.355-287.750.amzn2、Kernel 5.10 Extraはkernel-5.10.269-270.1108.amzn2

コンテナインスタンスをDRAININGにしてタスクを逃がしてから更新・再起動するか、起動テンプレートのAMIを最新のECS最適化AMIに替えてインスタンスリフレッシュを行います。どちらの場合も、再起動後に uname -r で修正版のカーネルで起動していることを確かめてください。パッケージを更新しても、再起動するまでは古いカーネルのまま動いています。

ベアメタルインスタンスやネストした仮想化で、EC2上にKVMやFirecrackerを載せている場合は、AWSの速報が「影響を受ける製品」として挙げる構成そのものなので、最優先です。

ディストリビューション別の状況（10月17日確認）

・Amazon Linux 2／2023：修正版を公開済み
・AlmaLinux 8／9／10：テスト用リポジトリで修正版を公開。本番リポジトリへは検証後
・RHEL 8／9／10：影響あり。10月16日時点で修正版は未公開
・Debian：trixieは6.12.113-1（DSA-6568-1）で修正。bookwormは未修正
・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 で新しいカーネルを確認する

ブログの記事では、Docker（Docker Desktopを含む）、ECS、VPSを借りている場合の考え方、確認コマンド、参考資料の一覧まで載せています。本文の確認コマンドは一般的な手順で、筆者が各環境で実行して確かめたものではありません。

※2026年10月17日時点の公開情報に基づきます。修正状況は日々変わるため、対応前に各社の最新の告知を確認してください。

自社の構成が対象になるかの判定や、ECS・EKSのノード更新の段取りについてのご相談は、30分の無料相談で承っています。

https://shinichi.noguchi.jp.net/blog/2026-10-17-cve-2026-99999-pwnescape-docker-ecs.html