Docker Desktopのログに外部のAPIキー 4.97.0で修正、送った診断も削除を

Docker Desktopを4.97.0に上げれば、それで終わりでしょうか。片づくのはそのPCの中だけで、更新の前に作った診断のファイルや、別の場所へ写したログには、Docker以外のサービスのAPIキーが平文で残っているかもしれません。

4.97.0が出たのは2026年10月26日で、翌27日にこの脆弱性がCVE-2026-114409として登録されました。告知は、4.96.x以前で診断のファイルを作ったり人に渡したりした場合と、ログの写しをほかに置いている場合に、それらを「削除するか、伏せる」よう求めています。

開発者のPCにDocker Desktopを入れている会社では、版を上げる作業と、写しを探す作業の2つが要ります。後のほうは、ふだんの更新の手順には入っていません。

預かった外部のキーが、ログに書かれていた

CVEの記録によると、対象は2025年3月に出た4.39.0から、4.97.0より前までの版です。Windows、Mac、Linuxのどれも含みます。アプリの内部でやり取りする情報を伏せる処理が足りず、Docker Desktopに預けたAPIキーとOAuthのアクセストークンが、ログと診断のファイルにそのまま書かれることがありました。

このOAuthのトークンについて、Dockerは「Dockerアカウントのトークンではない」と断っています。Docker Hubへのサインインとは別の、外部のサービスにつなぐための情報です。

修正は、実は2段階でした。10月5日の4.94.0で「保存したAPIキーがログに平文で書かれ、診断のファイルに入る」問題を直し、4.95.0までに分かっていた経路はふさがれています。ところが、それまでに書かれたログは、更新しても消えずに残っていました。4.97.0で修正を終え、PCの中にある古いログとクラッシュダンプの掃除も加わったわけです。

深刻度はCVSS 4.0で5.7、警告の水準。攻撃者がファイルを読めることが前提で、外から直接狙われる種類ではありません。そのぶん、ファイルがどこまで広がったかで危なさが決まります。

ログに秘密が入る脆弱性は、これで5件目

Docker Desktopのリリースノートとセキュリティの告知をさかのぼると、ログや診断のファイルに秘密の情報が入る脆弱性は、CVEが付いたものだけで、1年7か月あまりに5件ありました。

表の1行目の4.39.0は、今回の対象の始まりの版でもあります。

Dockerは、見つかるたびに伏せる処理を足してきました。しかし、診断のファイルにはアプリの中で動いた情報がまとめて入るので、別の経路がまた見つかってもおかしくありません。版にかかわらず、診断のファイルは秘密を含みうるものとして扱うのが現実的でしょう。

対象になるPCと、対象外のもの

キーが書かれうるのは、4.39.0〜4.96.xのDocker Desktopで、外部のサービスのAPIキーを登録したり、OAuthでつないだりしたPCです。キーを預けていなければ、ログに書かれるものもありません。開発者に「Docker Desktopの画面から、ほかのサービスとつないだか」を聞くのが早道です。

告知に書かれていないことも2つあります。どの機能で預けたキーが書かれたのかと、Dockerにアップロード済みの診断をどう扱うのかです。

4.97.0から使い始めたPCは対象外です。Docker Hubのアカウントのトークンも、今回は対象に入っていません。

4.97.0では、もう1件、CVE-2026-99999も修正されました。Linuxカーネルの脆弱性PwnEscapeです。仮想マシンからホストへ抜けられるとして、国内でもVPS事業者が新規の申し込みを止めました。Docker Desktopはコンテナを専用のLinuxの仮想マシンで動かすため、その中のカーネルが対象でした。Dockerの説明では、コンテナがTUNかAF_PACKETを使って不正なチェックサムの情報を流し、仮想マシンのネットワーク処理を壊せるといいます。出どころの分からないイメージを開発者のPCで動かすことがあるなら、こちらも急ぐ理由になります。

4.96.1〜4.96.3では、鍵が破られたeMudhraの中間CAの証明書を信頼しない変更も入りました。4.95.0以前から4.97.0に上げれば、まとめて済みます。

4.97.0を配る前に確認すること

開発者に任せていると、版はばらばらになりがちです。10月12日にはWindowsのインストーラーの脆弱性で、4.92.0以降への更新が要りました。そのときに作ったPCの一覧があれば、今回も使えます。

1. 入っているPCと版を洗い出す。Windowsでは、ユーザーごとのインストールなら%LOCALAPPDATA%\Programs\DockerDesktop、全員向けならC:\Program Files\Docker\Dockerに入ります。ユーザーごとのインストールはレジストリもHKCUに書かれるので、資産管理のツールがHKLMしか見ていないと、一覧から漏れることがあります。4.97.0からは、EXEで新しく入れるとユーザーごとのインストールが既定になりました。
2. 各PCの版は、docker versionのServerの行に「Docker Desktop 4.97.0」のように出ます。4.96.x以前のPCを、配る先の一覧にします。
3. 更新が止まっていないかを見る。MSIで配ったPCは、アプリの中の更新が初めから止まっています。Docker Homeの設定でdisableUpdateをオンにしてロックしている会社も同じです。この場合は、Docker HomeのDeployのページから4.97.0のMSIを取り、Intuneなどで配り直します。
4. アプリの中の更新に任せるPCも、すぐには届かないことがあります。Dockerは新しい版を段階的に配っていて、届くまでにふつう1週間ほどかかると案内しています。待てないPCには、リリースノートのページから入れてもらいます。

MSIの更新が止まるのは、会社が認めていない版が入らないようにするための仕組みです。その代わり、今回のような更新は情シスが配らないかぎり届きません。

診断とログの写しを片づける手順

写しがありそうな場所は、思ったより多いはずです。Dockerの手引きの例では、診断を集めるとzipのファイルがPCに残り、Windowsは利用者のTempフォルダーの下、MacとLinuxは/tmpの下に置かれます。そのzipを、社内の問い合わせやチャットに添付して相談した開発者もいるでしょう。

1. 社内の問い合わせの記録で、Docker Desktopの診断のファイルが添付された件を探し、添付を消す。チャットや共有のフォルダーに置いたものも同じです。
2. 開発者のPCに残った診断のzipを消してもらう。4.97.0が掃除するのはログとクラッシュダンプなので、Tempや/tmpのzipは自分で消すほうが確実です。
3. ログを集めている仕組みを調べる。ログの収集の仕組みやEDRがDocker Desktopのログのフォルダーを取り込んでいるなら、取り込んだ先で古いログを消すか、キーの部分を伏せます。PCのバックアップにも、古いログが入っている場合があります。
4. Dockerに送った診断を控える。アプリの「Upload」やcom.docker.diagnoseの-uploadで送ると、ファイルはDockerに渡り、手元には診断IDが残ります。GitHubのIssueに書くのは、この診断IDだけです。送った診断の扱いが気になるなら、診断IDを添えてDockerのサポートに問い合わせます。

キーを出し直すかどうかは、写しがだれの目に触れたかで決めるのがよいでしょう。編集部の考える目安は次のとおりです。

出し直すときは、発行元のサービスの管理画面で、古いキーを必ず無効にします。新しいキーをDocker Desktopに登録しただけでは、漏れたかもしれないキーが生きたままです。

開発者から「Dockerが起動しない」と相談されると、まず診断のファイルを送ってもらいたくなります。ただ、5件の前例を見るかぎり、版が新しくても、診断のファイルにまた何かが紛れ込むことはありえます。受け取ったら、相談が片づいた時点で消す。そう決めておくだけで、次に同じ告知が出たときに探す場所が1つ減ります。