Docker DesktopのWSL 2で隔離回避を修正｜両方の更新と再起動後の確認を

WindowsでDocker DesktopのWSL 2バックエンドを使っている開発者は、Docker Desktop 4.98.0以降とWSL 3.0.3以降の両方に更新してください。Dockerは2026年11月3日付の4.98.0で、Linuxコンテナからホスト側への通信を制限する仕組みを回避できる脆弱性CVE-2026-112917を修正しました。ただし、アプリを修正版にしてもWSLが古いままでは対策が完了しません。端末管理者は、インストール済みアプリの一覧だけでなく、WSLの実行環境まで確認する必要があります。

影響を受けるのはどの構成か

Docker Desktop 4.98.0の公式リリースノートは、WSL 2バックエンドのコンテナがAF_VSOCKの制限を回避できたと説明し、修正にはWSL 3.0.3以降が必要と明記しています。OpenCVEに掲載されたDockerのCVE登録データで示されている対象は、x86-64のWindowsホスト上でWSL 2をバックエンドに使うDocker Desktopです。LinuxKitベースのバックエンドは対象外とされています。この条件を、Windowsで動くすべてのDocker製品や、Linuxサーバーに直接導入したDocker Engineへ広げないでください。

WSLをインストールしていることと、Docker Desktopがそれをバックエンドとして使っていることは別です。Docker Desktopの設定で実際のバックエンドを確認し、Linuxコンテナをどの実行環境で動かしているかを記録します。別の環境に接続したDocker CLIから正常にコマンドが通っても、手元のDocker Desktopが何を使っているかは分かりません。反対に、普段はリモート環境だけを使っている場合でも、ローカルで対象のバックエンドを起動して使う端末は棚卸しに含めます。

Dockerの登録データでの評価はCVSS 4.0で9.2です。攻撃の起点は、影響を受けるLinuxコンテナ内でコードを実行できることです。インターネットから対象のWindows端末へ接続できるだけで成立するという説明ではありません。今回確認したDockerとMicrosoftの公式リリース資料には、実環境での悪用を確認したとの記載はありません。深刻度の数値と、個々の端末への侵害の有無は分けて判断します。

非特権コンテナでも制限を回避できた理由

AF_VSOCKは仮想マシンとホストなどの間で使われるソケットのアドレスファミリーです。今回問題になったのは、Docker DesktopのWSL 2バックエンドで、Linuxコンテナに適用される既定のseccomp制限です。Dockerの登録データによると、通常の呼び出しで制限される操作に対して、32ビット互換のsocketcallという別の経路を使うと、非特権コンテナでも制限を回避できました。公開ポートを増やす不具合ではないため、Composeのポート公開設定だけを調べてもこの経路は確認できません。

制限を回避すると、ホスト側のサービスに接続できる可能性があります。Windows上のファイルへの影響についてDockerは、到達できるホスト側AF_VSOCKサービスがあることを条件に挙げています。影響はログイン中のWindowsユーザーがアクセスできるファイルなどに及び得ますが、制限を回避できたことだけで、すべての端末で任意のファイルにアクセスできる、あるいはWindowsの管理者権限を得られるとは言えません。コンテナのユーザーを非rootにする設定は引き続き有用ですが、今回の更新の代わりにはなりません。

開発端末で注意したいのは、外部から入手したイメージ、外部の変更を含むブランチのビルド、開発コンテナの初期化処理などです。これらを扱うこと自体が侵害の証拠という意味ではありません。実行されるコードを信頼できるか、検証に使う端末と、ソースや配備用の認証情報を扱う端末を分けられるかが、更新までの運用判断になります。端末の棚卸しでは、開発者のPCに加え、Windows上のDocker Desktopを実際に使う検証用端末や共用環境も含めます。

片方だけ更新した端末を見落とさない

対応の基準はDocker Desktop 4.98.0以上、WSL 3.0.3以上です。MicrosoftのWSL 3.0.3リリースノートでは、このリリースがMicrosoftのWSLカーネルを6.18.54.1へ更新したことを確認できます。Docker Desktopの版番号、WSLパッケージの版番号、WSLカーネルの版番号は別です。棚卸し表でもそれぞれ列を分け、Docker Desktopの更新だけを根拠に「完了」と記録しないようにします。

Docker Desktopが古い端末は、WSLだけを更新しても公式の修正条件を満たしません。逆にDocker Desktopが4.98.0以上でも、WSLが3.0.3未満なら対象の構成は影響を受けたままです。両方のバージョンが基準を満たした端末について、再起動後に実際の環境で反映を確認します。なお、組織でWSLのカーネルを独自に指定している場合は、標準カーネルを使う環境と同じ扱いにせず、指定したカーネルに必要な修正があるかを管理者と確認します。

端末への更新配布が二つの仕組みに分かれている組織では、同じ端末を対象にした配布状況を突き合わせます。Docker Desktopを管理ツールで更新していても、WSL側の更新がMicrosoft Storeの利用制限や別の承認手順で保留される場合があります。利用者に作業を依頼するなら「Docker Desktopを最新版へ」とだけ伝えず、二つの最低版と、確認に使う画面やコマンドを示します。利用者が更新の権限を持たない端末では、管理側の配布が確認できるまで完了扱いにしません。

更新と確認をPowerShellから進める

Docker Desktopの版はアプリのバージョン表示で確認します。Docker CLIの版はそれとは別なので、docker --versionだけを証跡にしないでください。WSL側はPowerShellで次のコマンドを使います。Microsoft LearnのWSL基本コマンドに、バージョン表示と更新、WSLの停止方法がまとまっています。

wsl --version
wsl --update
wsl --version

最初のwsl --versionでWSLとカーネルの版を記録します。wsl --updateはWSLの更新操作で、Docker Desktopの更新は承認済みの配布経路で別途行います。最後に表示した版が最低条件に届かなければ、更新コマンドが終了したことだけで修正済みと判断しません。標準の配布経路が使えない場合、Microsoftはwsl --update --web-downloadも案内していますが、企業端末では管理者が許可する経路を選びます。コマンドの利用可否や表示が想定と異なる端末は、WSLの導入方法と配布状況を個別に確認します。

新しい実行環境に切り替えるため、動いている開発サーバーやビルドを停止し、編集中のファイルを保存してからDocker Desktopを終了します。必要に応じてwsl --shutdownでWSLの仮想マシンを止め、Docker Desktopを起動し直します。このコマンドはDocker Desktopだけでなく、動作中のWSLディストリビューションも終了させます。共用端末で他の処理がないことを確認し、インストーラーからWindowsの再起動を求められた場合はその案内に従います。データの削除や工場出荷時設定へのリセットは、この確認手順に含めません。

再起動後は接続先と通常動作を確かめる

再起動したら、同じWindows端末上でDocker Desktopの版、バックエンド、WSLの版を読み直します。Docker CLIで動作を確認する場合は、docker context showなどで接続先を確かめ、環境変数やコマンドの指定で別のデーモンを選んでいないことも見ます。普段と同じ開発環境から、組織が信頼している既存イメージでコンテナを起動し、必要な開発用ファイルの共有や通常のテストが通るかを確認します。これは更新後の動作確認であり、脆弱性の再現試験ではありません。

版が基準を満たしているのにDocker Desktopが起動しない場合は、WSLの状態とDocker Desktopの診断情報を別々に確認します。Docker CLIが応答しないだけでは、WSLが起動できないのか、接続先が違うのか、Dockerの起動処理が止まったのかを区別できません。まずアプリ側の表示と接続先を調べ、次にWSLの状態を確認します。古い版へ戻せば動く場合でも、その版のまま未検証のコンテナを実行してよいという判断にはなりません。

端末管理では、最後に「両方更新して再起動・確認済み」「片方が未更新」「構成確認中」「今回の対象外」を分けます。対象外の理由は、たとえば対象のDocker Desktopバックエンドを使用していないことなど、端末ごとに根拠を残します。配布の進捗をアプリ更新率だけで集計すると、WSL側の未更新端末が消えてしまいます。版の組み合わせを作業記録に残しておけば、再配布の対象も絞り込めます。

更新を待つ間にできること

修正版の導入まで時間がかかる端末では、本サイトとして、信頼できないイメージや外部の変更を含むビルドを対象環境で実行しないことを勧めます。既に実行中の検証ジョブを止める必要があるかは、何を実行し、同じWindowsユーザーで何にアクセスできるかを基に判断します。別の端末へ移す場合も、修正が確認された環境を選びます。ポート公開を閉じる、コンテナを非rootにする、マウントを見直すといった対策には個別の価値がありますが、今回の修正条件を満たしたことにはなりません。

不審な実行が見つかった場合は、対象端末、DockerとWSLの版、コンテナの起動時刻やイメージの参照、当時のログインユーザーを記録し、端末管理やインシデント対応の担当者へ引き継ぎます。ホスト側ファイルが影響を受け得るという説明を手がかりに、当時のユーザーが利用できた開発用の資格情報や共有ファイルを切り分けます。ログに異常が見当たらないことだけで過去の影響を否定することはできず、反対に対象版だったというだけで情報流出が確定するわけでもありません。版の確認と影響の調査は別の作業として扱います。

関連記事

Dockerソケットを渡す前に確認する管理権限とSSH接続の守り方