WSL2とDocker利用者がCVE-2026-31431で確認したいこと｜Copy Failの影響範囲と更新ポイント

Linuxカーネルの権限昇格脆弱性として、CVE-2026-31431 / Copy Fail が公開されています。

Windowsだけを普通に使っている場合は関係が薄い話に見えますが、WSL2、Docker Desktop、Linuxコンテナ、開発用Ubuntu / Debian環境を使っている場合は、確認しておいた方がよい内容です。

この記事では、Windows上でWSL2やDockerを使っている人向けに、CVE-2026-31431 / Copy Failで何を確認すればよいかを整理します。

なお、この記事では攻撃手順、PoCの再現方法、悪用コードは扱いません。自分が管理しているPC、許可された開発環境、業務で使っているWSL2 / Docker環境の更新確認を目的にしています。

先に結論：WSL2とDocker利用者は更新状況を確認する

CVE-2026-31431 / Copy Fail は、ネットワーク越しに直接攻撃されるタイプの脆弱性ではなく、ローカルで一般ユーザー権限を持つことが前提の権限昇格脆弱性として扱われています。

ただし、WSL2やDockerのようにLinuxカーネルやコンテナ環境を使う場合は、次の点を確認しておくのが安全です。

確認対象	確認すること	優先度
WSL2	WSLのバージョン、WSLカーネル、利用中ディストリビューション	高
Docker Desktop	Docker Desktop本体とDocker Engineの更新状況	高
Docker Engine	Engine 29.4.2以降のhardening情報、seccomp設定	高
Linuxディストリビューション	Ubuntu / Debian / Fedora / Red Hat系などのセキュリティ更新	高
コンテナ運用	特権コンテナ、seccomp無効化、ホスト共有の有無	中〜高
暫定対策	公式情報と副作用を確認してから判断	中

最優先は、WSL、Docker、利用中Linuxディストリビューションの更新状況を確認することです。攻撃コードを試す必要はありません。

CVE-2026-31431 / Copy Failとは

CVE-2026-31431 / Copy Fail は、Linuxカーネルに関係する権限昇格脆弱性です。

IPAの注意喚起では、この脆弱性を悪用された場合、当該製品上でローカルにログイン可能な一般ユーザーにより、管理者権限を取得される可能性があると説明されています。

重要なのは、これは「インターネット越しに誰でも直接攻撃できる」という種類のものではない点です。ローカルユーザー権限が前提です。

一方で、検証コードが公開されていること、コンテナのように複数の環境でカーネルを共有する運用では影響が懸念されることから、WSL2やDockerを使っている場合は放置せず確認しておくべきです。

Windowsユーザーでも関係する可能性があるケース

通常のWindowsアプリだけを使っている場合と、WSL2やDockerを使っている場合では確認すべき範囲が変わります。

利用状況	確認要否	理由
WSLを使っていない	低	Linuxカーネルを直接使っていないため
WSL1のみ利用	低〜中	WSL2とは仕組みが異なるが、利用環境の確認は推奨
WSL2を利用	高	WSL2はLinuxカーネルを使うため
Docker Desktopを利用	高	LinuxコンテナやWSL2バックエンドを使う場合があるため
Linux VMを利用	高	仮想マシン内のLinuxカーネル更新が必要になるため
CI/CDや共有開発環境でDockerを利用	高	複数ユーザー・複数コンテナで影響が広がりやすいため

特に注意したいのは、開発PCでDocker Desktopを入れているが、普段はLinuxカーネルを意識していないケースです。

Docker Desktop、WSL2、Ubuntuなどを使っている場合は、Windows Updateだけでなく、WSLやLinuxディストリビューション側の更新も確認してください。

まずWSL2を使っているか確認する

最初に、自分のPCでWSL2を使っているか確認します。PowerShellまたはコマンドプロンプトで、次のコマンドを実行します。

wsl --list --verbose

または短縮形で次のようにも確認できます。

wsl -l -v

表示された一覧の「VERSION」が 2 になっているディストリビューションがあれば、その環境はWSL2で動作しています。

あわせて、WSL自体のバージョンと状態も確認します。

wsl --version
wsl --status

WSL2を使っている場合は、次の更新確認へ進みます。

WSLを更新する

Microsoft Learnでは、WSLを更新するコマンドとして次のコマンドが案内されています。

wsl --update

更新後は、WSL環境をいったん停止して再起動するのが安全です。

wsl --shutdown

その後、もう一度WSLやDocker Desktopを起動して確認します。

会社PCや管理対象PCの場合、WSLの更新やMicrosoft Store経由の更新が管理者ポリシーで制限されていることがあります。その場合は、社内のIT管理者や管理ルールに従ってください。

WSL内のLinuxディストリビューションも更新する

WSL本体だけでなく、WSL内で使っているUbuntu、Debian、FedoraなどのLinuxディストリビューション側の更新も確認します。

まず、WSL内で利用中のディストリビューション情報とカーネル情報を確認します。

cat /etc/os-release
uname -a

UbuntuやDebian系の場合は、通常は次のような流れでパッケージ更新を確認します。

sudo apt update
sudo apt upgrade

Fedora系の場合は、次のようなコマンドで更新を確認します。

sudo dnf upgrade

Red Hat Enterprise Linux系や会社管理のLinux環境では、契約、リポジトリ、社内配布ルールに従って更新してください。

ここで重要なのは、ネットの記事だけを見て暫定対策を入れるのではなく、自分が使っているディストリビューションの公式セキュリティ情報と更新パッケージを確認することです。

Docker Desktop / Docker Engineを確認する

Dockerを使っている場合は、Docker DesktopとDocker Engineのバージョンを確認します。

PowerShell、コマンドプロンプト、またはターミナルで次のコマンドを実行します。

docker version
docker info

Docker Desktopを使っている場合は、Docker Desktopの画面から更新確認を行います。会社PCでは、自動更新が止められていることもあるため、管理ルールも確認してください。

Docker Engine 29.4.2のリリースノートでは、CVE-2026-31431に関連するhardeningとして、デフォルトseccompプロファイルでAF_ALG socketsとsocketcall(2) multiplexerをブロックする対応が記載されています。

そのため、Docker利用者は少なくとも次の点を確認しておくと安全です。

Docker Desktopが最新になっているか
Docker Engineのバージョンが古くないか
Docker公式リリースノートでCVE-2026-31431関連の記載を確認したか
デフォルトseccompプロファイルを無効化していないか
不要に --privileged コンテナを使っていないか
ホスト側の重要なディレクトリをコンテナへ過剰にマウントしていないか
共有開発PCやCI環境で不特定多数のコンテナを動かしていないか

特に、検証用だからという理由で --privileged やseccomp無効化を常用している場合は、見直し対象です。

Dockerで確認したい運用上のポイント

CVE-2026-31431はローカル権限昇格の脆弱性として扱われています。そのため、Docker環境では「コンテナ内からホスト側へ影響が広がりやすい設定になっていないか」を確認することが重要です。

確認項目	避けたい状態	確認方針
seccomp	理由なく無効化している	デフォルト設定を基本にする
特権コンテナ	`--privileged` を常用している	必要な時だけ限定して使う
ボリュームマウント	ホストの重要ディレクトリを広く共有している	必要最小限にする
共有開発環境	複数人が同じホストで自由にコンテナを動かす	権限とログを整理する
古いイメージ	更新されていないベースイメージを使い続ける	ベースイメージの更新も確認する

開発用PCでは、便利さを優先して権限を広げたままにしがちです。今回のようなLinuxカーネルの脆弱性では、Docker本体の更新だけでなく、コンテナの権限設定も見直しておく価値があります。

Windows Updateの不具合として扱わない

CVE-2026-31431 / Copy Fail は、Windows Updateの不具合ではありません。

Windows上で影響を意識する場面は、WSL2、Docker Desktop、Linux VM、Linuxコンテナなど、Linuxカーネルを利用する環境を使っている場合です。

そのため、確認の順番は次のようになります。

Windows Updateだけで判断しない
WSL2を使っているか確認する
WSLを更新する
WSL内のLinuxディストリビューションを更新する
Docker Desktop / Docker Engineを更新する
利用中ディストリビューションの公式セキュリティ情報を確認する

Windows側が最新でも、WSL内のディストリビューションやDocker側が古いままということはあります。

暫定対策を書く前に注意したいこと

ネット上では、特定モジュールの無効化、設定ファイルの変更、カーネル機能の制限など、暫定対策に関する情報が出ることがあります。

ただし、こうした設定変更は環境によって副作用が出る可能性があります。暗号化、VPN、コンテナ、開発ツール、検証環境に影響する場合もあります。

そのため、暫定対策を入れる場合は、次の条件を満たしてから判断するのが安全です。

IPA、Microsoft、Docker、利用中ディストリビューションの公式情報を確認した
自分の環境で本当に必要か確認した
副作用が出た場合に戻せる手順を用意した
会社PCの場合は管理者や社内ルールの承認を得た
本番環境では事前に検証環境で確認した

更新パッケージが提供されている場合は、基本的には公式の更新適用を優先します。

やってはいけない確認方法

脆弱性情報を確認する時に、やってはいけない確認方法もあります。

PoCコードを本番PCや会社PCで実行する
攻撃手順を試して影響有無を確認する
自分の管理外のサーバーや共有環境で検証する
許可なく会社環境や顧客環境でテストする
出所不明のスクリプトをそのまま実行する
脆弱性を理由に不要な権限変更を行う

脆弱性の有無を確認したい場合でも、攻撃手順を試す必要はありません。公式情報、パッケージ更新状況、Docker / WSL / ディストリビューションのバージョン確認を優先してください。

個人PCと会社PCで確認の重さを変える

個人PCと会社PCでは、確認の重さを変えるべきです。

環境	確認方針
個人PC	WSL、Docker、Linuxディストリビューションを更新し、不要な特権コンテナを避ける
会社支給PC	勝手に暫定対策を入れず、管理者・社内ルールに従う
開発用共有PC	複数ユーザー・複数コンテナの権限範囲を確認する
CI/CD環境	Docker Engine、ランナー、ベースイメージ、権限設定を確認する
本番サーバー	ディストリビューションの公式セキュリティ情報と運用手順に従う

特に会社PCでは、個人判断で設定ファイルを書き換えるより、管理者側でWSLやDocker Desktopの更新方針を決める方が安全です。

確認用チェックリスト

最後に、WSL2 + Docker環境でCVE-2026-31431 / Copy Failを確認する時のチェックリストをまとめます。

WSLを使っているか確認した
WSL2のディストリビューションがあるか確認した
wsl --version でWSLのバージョンを確認した
wsl --status でWSLの状態を確認した
wsl --update でWSL更新を確認した
wsl --shutdown 後に再起動した
WSL内のUbuntu / Debian / Fedoraなどを更新した
uname -a でカーネル情報を確認した
Docker Desktopを更新した
docker version でDocker Engineのバージョンを確認した
Docker Engine 29.4.2以降のリリースノートを確認した
seccompを不要に無効化していないか確認した
--privileged コンテナを常用していないか確認した
ホスト側の重要ディレクトリを広くマウントしていないか確認した
利用中ディストリビューションの公式セキュリティ情報を確認した
PoCや攻撃コードを実行して確認しようとしていない

参考：公式情報

確認する場合は、SNSや個人ブログだけでなく、公式情報を優先してください。

まとめ

CVE-2026-31431 / Copy Fail は、Linuxカーネルに関係するローカル権限昇格脆弱性です。

Windowsユーザーでも、WSL2、Docker Desktop、Linuxコンテナ、Linux VMを使っている場合は、自分の環境が影響を受ける可能性があるため、更新状況を確認しておくべきです。

まずは、WSLのバージョン、WSLカーネル、利用中ディストリビューション、Docker Desktop / Docker Engineのバージョンを確認してください。

一方で、PoCや攻撃手順を試して確認する必要はありません。公式情報と更新状況を確認し、必要に応じて管理者や利用中ディストリビューションの案内に従って対応するのが安全です。

Windowsやセキュリティ更新に関する記事は、以下も参考にしてください。

WSL2とDocker利用者がCVE-2026-31431で確認したいこと｜Copy Failの影響範囲と更新ポイント

先に結論：WSL2とDocker利用者は更新状況を確認する

CVE-2026-31431 / Copy Failとは

Windowsユーザーでも関係する可能性があるケース

まずWSL2を使っているか確認する

WSLを更新する

WSL内のLinuxディストリビューションも更新する

Docker Desktop / Docker Engineを確認する

Dockerで確認したい運用上のポイント

Windows Updateの不具合として扱わない

暫定対策を書く前に注意したいこと

やってはいけない確認方法

個人PCと会社PCで確認の重さを変える

確認用チェックリスト

参考：公式情報

まとめ

この記事を共有

Windows11 関連の相談先・運営者情報

関連記事

OBSで「Skipped frames due to encoding lag」が出る時の確認ポイント｜NVENC・AV1・GPU負荷・出力設定を確認

OBSでゲームキャプチャが映らない時の確認ポイント｜黒画面・管理者実行・オーバーレイ・HAGSを確認

Windows 11 26H1とは？既存PCに配信されない理由と24H2・25H2で確認したいこと

Chromeの更新確認方法｜147/148の見方とWindowsで安全に更新する手順