タグ: linux

Docker DesktopにCritical脆弱性、CVE-2025-9074 ─ macOS・Linuxも含め更新推奨

コンテナ技術は、開発から運用まで幅広い現場で欠かせない存在となっています。その中でも Docker Desktop は、Windows・macOS・Linux などの環境で簡単に Docker を利用できるツールとして、多くの開発者やエンジニアに利用されています。日常的にローカル開発環境を立ち上げたり、テスト用に複数のコンテナを起動したりする用途で広く普及しており、影響範囲は非常に大きいと言えます。

今回報告された脆弱性 CVE-2025-9074 は、そうした日常的に利用される開発環境に潜む重大なリスクです。影響は特定の設定や条件に限定されず、Enhanced Container Isolation（ECI）や「Expose daemon」設定の有無にかかわらず影響を受けることが判明しています。これにより、普段はセキュアだと考えていた環境でも、不正アクセスやコンテナ制御の乗っ取りといった深刻な被害に発展する可能性があります。

特に Windows 環境では、WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクが確認されていますが、macOS や Linux でも同様にコンテナ間の不正制御が可能になるため、「Windows ユーザーだけが対象」ではなく、すべての Docker Desktop ユーザーが直ちにアップデートすべき事案です。

Docker 側は迅速に修正版をリリースしており、2025年8月20日に公開された Docker Desktop 4.44.3 で本脆弱性が修正されています。本記事では、脆弱性の詳細とリスク、そしてユーザーが取るべき対策について整理します。

脆弱性の概要

今回報告された CVE-2025-9074 は、Docker Desktop 上で稼働する Linux コンテナが、本来アクセスできないはずの Docker Engine API に直接アクセスできてしまうという脆弱性です。Docker Engine API はコンテナのライフサイクル管理やイメージ操作などを行うための強力なインターフェースであり、ここに不正アクセスされると、ユーザーの意図しない操作が可能になってしまいます。

この問題の本質は、Docker Desktop が内部で利用している サブネット経由の通信経路にあります。通常であれば、セキュリティ設定やネットワークの分離によってコンテナからホスト側の管理 API へ直接到達できないように設計されています。しかし、今回の脆弱性では、その設計をすり抜ける形でアクセスが可能となり、結果として以下のようなリスクが生じます。

  • 不正なコンテナ制御: 攻撃者が任意に新しいコンテナを生成したり、既存コンテナを停止・削除したりできる。
  • イメージの操作: ローカルに保存された Docker イメージを削除、改ざん、あるいは外部に流出させる可能性。
  • 設定の改変: 環境構築や開発に利用する設定を不正に変更される危険性。

さらに問題を深刻化させているのは、この挙動が ECI（Enhanced Container Isolation）や「Expose daemon」の設定有無に依存しない という点です。つまり、セキュリティオプションを強化していたとしても、今回の脆弱性を防ぐことはできません。

また、Windows 環境においては、WSL バックエンドを利用している場合、通常は制御できない ホストドライブがユーザー権限でマウントされる リスクが確認されています。これはシステム内のファイルが意図せず外部から参照・改変されることにつながり、開発用 PC の安全性を直接脅かす可能性があります。

一方で macOS や Linux 環境においても、Docker Engine API の権限を奪取されれば同様にコンテナ制御やイメージ操作が行われるため、プラットフォームに依存しない深刻な脅威となっています。

今回の脆弱性は CVSS v4.0 ベーススコア 9.3（Critical） として評価されており、最も高い深刻度レベルに分類されています。この評価は、単なる理論的リスクではなく、現実に悪用された場合の影響が極めて広範囲かつ深刻であることを意味しています。

影響範囲

今回の脆弱性 CVE-2025-9074 は、Docker Desktop を利用しているすべてのユーザーに影響を与える可能性があります。特定の環境や利用方法に限定された問題ではなく、Windows・macOS・Linux のいずれにおいても共通してリスクが存在する点が重要です。

まず Windows 環境については、特に WSL（Windows Subsystem for Linux）をバックエンドとして利用している場合に深刻な追加リスクが指摘されています。WSL 上の Linux コンテナからホストマシンのドライブをユーザー権限でマウントされる可能性があり、これによって開発者が扱うソースコードや機密データが不正に参照・改変される危険性が生じます。これは通常のコンテナ分離モデルでは想定されない挙動であり、ローカル開発環境全体が攻撃者に乗っ取られる可能性を意味します。

一方で macOS や Linux 環境でも安心はできません。Docker Engine API へのアクセスが可能になる点は共通しており、攻撃者がこの API を操作することで、以下のようなリスクが発生します。

  • 不正なコンテナの生成・削除・停止などによる環境の破壊
  • ローカルに保存された Docker イメージの不正利用や流出
  • 開発環境に必要な設定やデータの改変によるサービス停止や混乱

つまり、「Windows 以外の環境では被害が軽い」とは言えず、開発環境に依存するすべてのユーザーが影響を受ける可能性があるのです。Docker Desktop は開発者にとって日常的に利用するツールであり、ローカル環境のコンテナ基盤そのものが脆弱化するという点で、被害の範囲は単一コンテナにとどまらず、開発プロジェクト全体、さらには組織内のリポジトリや CI/CD パイプラインに波及するリスクを孕んでいます。

加えて、今回の脆弱性は ECI（Enhanced Container Isolation）や「Expose daemon」設定の有無に依存せず影響するため、「セキュリティ機能を有効化しているから安全」と考えていたユーザーも例外ではありません。むしろ、多くの利用環境で普段通りにコンテナを実行しているだけで影響を受けるため、利用者全体を巻き込む普遍的な問題と言えます。

結論として、この脆弱性は 「Docker Desktop を利用するすべてのユーザーが対象」であり、特定のプラットフォームや構成に限定されたリスクではありません。そのため、Windows だけでなく macOS や Linux を利用している開発者やエンジニアも例外なく、迅速なアップデート対応が求められます。

対策

今回の脆弱性 CVE-2025-9074 に対しては、Docker 社がすでに修正版を公開しており、Docker Desktop 4.44.3 以降にアップデートすることで解消されます。現地時間 2025 年 8 月 20 日にリリースされたこのバージョンには、脆弱性を突いた不正アクセス経路を封じる修正が含まれており、ユーザー側で追加の設定変更を行う必要はありません。

重要な点は、設定や回避策では問題を防げないということです。ECI（Enhanced Container Isolation）の有効化や「Expose daemon」の無効化など、従来のセキュリティオプションを組み合わせてもこの脆弱性を防ぐことはできません。根本的な対策は Docker Desktop 自体を更新することに尽きます。

アップデート手順

１．現在のバージョンを確認

ターミナルで以下を実行し、Docker Desktop 4.44.3 以上であるかを確認します。

docker version

または、Docker Desktop Dashboardの右下に表示されているバージョンが4.44.3以上になっていることを確認します。

２．最新版の入手

Docker の公式サイト（https://www.docker.com/products/docker-desktop）から最新版をダウンロードします。Docker Desktop Dashboardの通知からでもダウンロード可能です。

３．Docker Desktopのアップデート

  • Windows / macOS: インストーラを実行し、既存の Docker Desktop に上書きインストール。
  • Linux: パッケージマネージャ（例: apt や dnf）を利用して更新、もしくは公式のインストーラを再適用。

４．アップデートの実行

右下がUpdateという表示になっている場合、これをクリックしてアップデートを行ってください。Software Updateページが表示されるので、更新を実施してください。

５．アップデート後の確認

  • 再度 docker version を実行し、クライアント・サーバともに 4.44.3 以上であることを確認。
  • 念のため、既存のコンテナが正常に動作するかテスト。

運用上の留意点

  • 全環境での更新を徹底: 個人開発環境だけでなく、チームメンバーや CI/CD 用のビルド環境など、Docker Desktop を利用しているすべての端末で更新が必要です。
  • 旧バージョンの利用を避ける: 脆弱性が公開されているため、旧バージョンを使い続けると攻撃者に狙われやすくなります。
  • 定期的なバージョンチェック: Docker Desktop は短いリリースサイクルで更新されるため、今回の件を機に定期的にバージョン確認を行い、常に最新を維持する運用を推奨します。
  • CI/CD パイプラインの確認: ビルド環境やテスト環境で Docker Desktop を利用している場合、更新漏れがあるとチーム全体のリスクにつながるため、パイプラインの実行ホストも忘れずに更新してください。

結論として、唯一の有効な対策は速やかなアップデートです。Windows 環境だけでなく macOS・Linux を含むすべての開発環境で Docker Desktop を利用しているユーザーは、今すぐバージョン確認を行い、必要に応じて更新を実施することが強く推奨されます。

おわりに

今回明らかになった CVE-2025-9074 は、Docker Desktop の根幹である Docker Engine API へのアクセス制御に関わる重大な脆弱性であり、影響範囲は Windows・macOS・Linux を含むすべての利用者に及びます。特定の環境に限定された問題ではなく、普段の開発作業やテスト環境、さらには CI/CD パイプラインにまで影響する可能性がある点が非常に危険です。

特に Windows 環境では WSL を介したホストドライブへのアクセスが可能になるなど追加的なリスクがありますが、これはあくまで一部の強調事例であり、macOS や Linux 環境でも Docker Engine API を乗っ取られることで同等の深刻な被害が生じ得ます。したがって、「Windows 以外は安全」と考えるのは誤りです。開発者がどの OS を利用していようと、この脆弱性を軽視すべきではありません。

Docker 社は迅速に修正版を提供しており、2025 年 8 月 20 日公開の Docker Desktop 4.44.3 で問題は解消されています。今回の事例から学べる重要な教訓は、脆弱性対策は「設定や部分的な防御策では不十分」であり、ソフトウェアを常に最新の状態に保つことこそが最も確実な防御策であるという点です。

また、個人開発者だけでなく、組織として Docker Desktop を利用している場合は、全メンバーの環境を一斉に更新する体制が不可欠です。ひとりでも古いバージョンを使い続ければ、その環境が攻撃者に狙われ、結果的にプロジェクト全体のセキュリティを損なう恐れがあります。特にクラウド連携やソースコード管理リポジトリと接続している開発環境では、被害が企業全体に波及する可能性すらあります。

さらに、今回の脆弱性に限らず、日常的なセキュリティ対策として 安全性が確認されていない不明なコンテナイメージを軽率に起動しない ことも重要です。公式リポジトリや信頼できる配布元以外から入手したコンテナには、脆弱性を悪用するコードやマルウェアが含まれる可能性があります。OS やツールを最新化することと同様に、利用するコンテナの信頼性を確認することも忘れてはなりません。

結論として、今すぐ Docker Desktop のバージョンを確認し、4.44.3 以上に更新することが最優先の対応です。加えて、怪しいコンテナを不用意に起動せず、信頼できるソースのみを利用することが、Docker 環境全体の安全を守るうえで不可欠な行動となります。

参考文献

IntelliJ IDEAで次の出現箇所を選択する

Visual Studio Codeでの❖+D/⌘+Dのような現在選択しているテキストと同じテキストが出現する次の箇所を選択するショートカットは、IntelliJ IDEAにも存在します。

ただ、WindowsとmacOSでショートカットが異なるので両方を使用している方は注意が必要です。

Windowsの場合

WindowsのIntelliJ IDEAでは、Alt+Jで現在選択しているテキストと同じテキストが次に出現する箇所を選択することができます。

macOSの場合

macOSのIntelliJ IDEAでは、^+Gで現在選択しているテキストと同じテキストが次に出現する箇所を選択することができます。

Linuxの場合

最近では開発用マシンとして使用している人もいるので、ちょっと調べてみました。Ubuntu 24.04 ARM64で動作確認を行っていますが、他のディストロやCPUでも変わらないかと思います。

結論からいうと、Windowsと同じAlt+Jで同様の操作ができました。macOSだけが異なるショートカットになっているため、こちらについても意識しておいた方がよいでしょう。

まとめ

Visual Studio Codeとは異なり、IntelliJ IDEAをはじめとするJetBrainsの製品はWindowおよびLinuxとmacOSでショートカットが異なります。これはCtrlキーとcommandキーの違いというような差異ではなく、使用するアルファベット自体が異なっている（まったくの別ショートカットとなっている）点に注意が必要です。

特に、私のようにプライベートと仕事で使用OSが異なる人は混乱しやすいと思いますので、OSを揃えるようにするなど何かしらの対策をしておいた方がよいかもしれません。

Linuxコマンドの代替・上位互換コマンドを使ってみよう – z, eza, fd, rg, bat, tldr

Linuxコマンドの代替コマンド、上位互換コマンドを紹介する動画を見ていて、知らないコマンドばかりだったので、実際に使ってみました。

コマンド自体はすべてmacOSでインストールして試しています。公式サイトのURLを付けていますので、その他のプラットフォームの場合は公式サイトご確認ください。

z – cdの代替コマンド

github.com
GitHub – ajeetdsouza/zoxide: A smarter cd command. Supports all major shells.
A smarter cd command. Supports all major shells. Contribute to ajeetdsouza/zoxide developm…

zはcdの代替コマンドです。cdコマンドと比べて移動に関する操作が強化されています。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install zoxide

インストール後、~/.zshrcに以下を追記し、シェルを再起動します。

eval "$(zoxide init zsh)"

使用方法

コマンドが違うだけで基本的にはcdコマンドと同じように使用できます。ただ、前にいたディレクトリへの復帰の方法がとても強力です。

$ z foo
$ mkdir -p bar/baz
$ mkdir -p abc/def
# foo/bar/bazディレクトリに移動する
$ z bar/baz
# 直前にいたfooディレクトリに戻る
$ z -
# 移動したことのあるbazディレクトリに直接移動する
$ z baz
$ z -
$ z abc/def
# 移動したことがあるなら直前にいたディレクトリでなくても移動可能
$ z baz
$ z def

2つ以上のディレクトリを行き来するときとかは重宝しそうです。

eza – lsの代替コマンド

github.com
GitHub – eza-community/eza: A modern alternative to ls
A modern alternative to ls. Contribute to eza-community/eza development by creating an acc…

ezaはexaからフォークしたコマンドで、現在はこちらがメンテナンスされているようです。

ezaはlsの代替コマンドです。lsコマンドよりも高い可読性の表示が簡単にできるのが特徴です。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install eza

使用方法

ezaや

eza -lで

色つきや下線がついた見やすい表示になります。

fd – findの代替コマンド

github.com
GitHub – sharkdp/fd: A simple, fast and user-friendly alternative to 'find'
A simple, fast and user-friendly alternative to 'find' – sharkdp/fd

fdはfindの代替コマンドです。特定の文字列を含むファイル名やディレクトリ名を簡単に探すことができます。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install fd

使用方法

複雑なオプションを使わずにファイルやディレクトリを検索できます。

# fooを含むファイル名、ディレクトリ名を現在のディレクトリから再帰的に検索する
$ fd foo
# ファイルのみを検索したいとき
$ fd --type f foo
# ディレクトリのみ検索したい場合
$ fd --type d foo
# fooを含むファイル名、ディレクトリ名をディレクトリbarを基点に再帰的に検索する
$ fd foo bar

findコマンドはオプションを色々覚えないといけないですし、環境やバージョンによってオプションが異なることがあるため、毎回調べる手間を大幅に削減できるのがうれしいですね。

rg – grepの代替コマンド

github.com
GitHub – BurntSushi/ripgrep: ripgrep recursively searches directories for a regex pattern while respecting your gitignore
ripgrep recursively searches directories for a regex pattern while respecting your gitigno…

rgはgrepの代替コマンドです。ファイルの中に文字列をGrepすることに特化したコマンドで、サクラエディタのGrep機能をコマンド化したような使い心地です。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install ripgrep

使用方法

オプションおよびコマンドの組み合わせなしでファイルの中身のGrepができます。

# 現在ディレクトリを基点に再帰的に'foo'が含まれる行を検索する
$ rg foo
# オプションなしで正規表現が使用可能
$ rg 'ba[rz]'
# 検索する基点となるディレクトリを指定可能（barディレクトリを基点に検索）
$ rg foo bar
# 拡張子を絞って検索することも可能
$ rg foo -g '*.css'

bat – catの代替コマンド

github.com
GitHub – sharkdp/bat: A cat(1) clone with wings.
A cat(1) clone with wings. Contribute to sharkdp/bat development by creating an account on…

batはcatの代替コマンドです。catコマンドよりも高機能かつ見やすい表示にしてくれます。

インストール方法

macOSへインストールするにはHomebrewを使用します。

brew install bat

使用方法

catと同じでファイル名を指定してファイルの中身を表示できるのは同じですが、moreコマンドなどと組み合わせる必要がなく、色も付けてくれるのでかなり見やすくなります。

tldr – manの補完コマンド

github.com
GitHub – tldr-pages/tldr: 📚 Collaborative cheatsheets for console commands
📚 Collaborative cheatsheets for console commands. Contribute to tldr-pages/tldr developmen…

こちらは代替コマンドというよりは補完するコマンドだと言えます。tldrコマンドで調べて、それでも不足している場合はmanコマンドで調べるという使い方がよさそうです。

インストール方法

macOSへインストールするにはHomebrewを使用します。かつてはtldrという名前でインストールできていたようですが、現在はtlrcという名前でインストールします。

brew install tlrc

使用方法

manコマンドと同じようにコマンド名を引数にします。

すっきりとした見た目なので非常にわかりやすいですね。さっと調べたい場合はtldrコマンドで調べて、もっと詳しくいろいろなオプションを調べたい場合はmanコマンドを使うようにするとよいと思います。

コマンドの使い方を調べるコマンドは他にもあるので簡単に紹介します。

cheat

github.com
GitHub – cheat/cheat: cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.
cheat allows you to create and view interactive cheatsheets on the command-line. It was de…

tldrと似ていますが、チートシートをローカルにダウンロードして、それを編集して自分で育てることができます。

$ brew install cheat
# コマンドを始めて調べるときはコミュニティ提供のチートシートをダウンロードできる
$ cheat sort
A config file was not found. Would you like to create one now? [Y/n]: y
Would you like to download the community cheatsheets? [Y/n]: y
Cloning community cheatsheets to /Users/t0k0sh1/.config/cheat/cheatsheets/community.
Enumerating objects: 335, done.
Counting objects: 100% (335/335), done.
Compressing objects: 100% (310/310), done.
Total 335 (delta 43), reused 213 (delta 23), pack-reused 0
Cloning personal cheatsheets to /Users/t0k0sh1/.config/cheat/cheatsheets/personal.
Created config file: /Users/t0k0sh1/.config/cheat/conf.yml
Please read this file for advanced configuration information.
# 以降はチートシートを表示する
# To sort a file:
sort <file>

# To sort a file by keeping only unique:
sort -u <file>

# To sort a file and reverse the result:
sort -r <file>

# To sort a file randomly:
sort -R <file>

# To sort a file and store the output in another file:
sort <inputFile> -o <outputFile>

# Sort by default uses /var/tmp to store temp files but size of /var/tmp directory is limited. In order to sort huge use a directory with adequate size:
sort -T <tempDirectory> <file>
# 一度ローカルに保存したチートシートは編集できる
$ cheat -e sort

howdoi

github.com
GitHub – gleitz/howdoi: instant coding answers via the command line
instant coding answers via the command line. Contribute to gleitz/howdoi development by cr…

プログラマ向けのQ&Aサイトから回答を調べて表示するコマンドです。

$ brew install howdoi
# JavaのStream APIでsortをするときの書き方を調べるにはキーワードを並べる
$ howdoi java stream sort
List result = list.stream().sorted((o1, o2)->o1.getItem().getValue().
                                   compareTo(o2.getItem().getValue())).
                                   collect(Collectors.toList());

まとめ

個人的にはfd、rgコマンドはこれからも使っていきたいと思いました。もちろん、シェルスクリプトではfindコマンドやgrepコマンドはこれからも使うと思います。

伝統的なコマンドを使いこなすことも重要ですが、使いにくいと思うコマンドを別のコマンドに置き換えてより効率的に作業をこなすのも重要なことだと思いますので、積極的に試していきたいと思います。

モバイルバージョンを終了