使用しているDockerコンテナイメージの内部を最後に確認したのはいつですか？なぜなら、これが厳しい現実だからです。コンテナを構成する全てのFROM命令、全てのコピーされたバイナリ、そして全てのインストールされたパッケージは、潜在的な攻撃ベクトルとなり得ます。
それは、コンテナイメージレイヤーとビルド時の依存関係を定期的に検査していない場合、認識しているよりもはるかに多くのリスクを継承している可能性が高いことを意味します。
CVE（共通脆弱性識別子）、安全でないベースイメージ、ハードコードされたシークレット、過剰な権限などは、攻撃者が侵入する経路のほんの一部に過ぎません。これは、貴社のような組織にとって懸念事項となるはずです。
実際、Red Hatの2024年コンテナセキュリティ現状レポート（600人のDevOps、エンジニアリング、セキュリティ専門家を対象に調査）によると、チームのほぼ半数（42%）がコンテナセキュリティのために夜も眠れないと認めています。
コンテナランタイムの脆弱性から、重要なGPUワークロードに影響を与えるCVEまで、この記事では最も重要でありながら見過ごされがちな9つのDockerコンテナの脆弱性を分析します。
Dockerコンテナの脆弱性とは何ですか？
Dockerコンテナの脆弱性とは、コンテナイメージ、ランタイム、またはその基盤となるインフラストラクチャ内のあらゆる弱点、設定ミス、または欠陥であり、攻撃者がセキュリティを侵害するために悪用できるものです。これには、よく知られたCVEだけでなく、不安全なデフォルト設定、露出したシークレット、過剰な権限などの見落とされた問題も含まれます。
Dockerコンテナが開発者にとって非常に強力であるそのスピードと移植性は、セキュリティチームにとっては悪夢となる可能性もあります。例えば、latestタグのイメージをプルしたり、コンテナをrootで実行したりすることは、最初は無害に見えるかもしれません。しかし実際には、これらは攻撃者が狙うまさにその種の開口部となります。
簡単に言えば、脆弱性とは、コンテナ設定において、侵入しようとする者にとって作業を容易にするあらゆるものです。
それらを踏まえて、注意すべき最も一般的で危険な9つのDockerコンテナの脆弱性を詳しく見ていきましょう。
Dockerコンテナにおける主要な脆弱性9選
以下の9つの脆弱性は、アクティブなCVEおよび本番環境で広く見られる設定ミスです。それぞれが、コンテナの侵害、ホストへのアクセス、またはインフラストラクチャ内でのラテラルムーブメントにつながる可能性のある実用的な脅威パスを表しています。
それらを詳しく見ていきましょう。
1. runCとDockerのコンテナブレイクアウトの脆弱性
RunCは、Dockerのような「高レベル」コンテナランタイムがコンテナを生成・実行するために主に使用する「低レベル」コンテナランタイムです。長年にわたり、RunCおよびDockerコンテナのブレイクアウト脆弱性が複数確認されており、それが攻撃につながっています。
主要な脆弱性の一つであるCVE-2019-5736は、2019年2月に発見されました。この脆弱性により、攻撃者はDockerバージョン18.09.2以前を実行しているrunCデプロイメントをエクスプロイトし、ホストのrunCバイナリを上書きすることで、ホストのルートアクセスを危険にさらすことが可能になりました。
古い脆弱性（2025年時点で6年前のもの）ではありますが、特にパッチが適用されていない、またはレガシーなDocker/runCバージョン、カスタムまたはフォークされたランタイムなどを使用する環境では、多くのチームが依然としてこれに晒されています。
CVE-2019-5736の脆弱性における重要なニュアンスは、コンテナプロセスがrootユーザーとして実行されている必要があるという点です。コンテナが非rootコンテナ（例：DockerfileでUSER 1000を使用、またはKubernetesでsecurityContext.runAsNonRoot: trueを使用）として実行されている場合、攻撃者は必要な権限がないため、上書きパスをトリガーできません。これが、コンテナをrootユーザーとして実行しないことが重要である理由です。
2019年以降、runCおよびDockerコンテナのブレイクアウト脆弱性が多数表面化しており、その中には深刻度が低いものから重大なものまであります。
- CVE-2024-21626: runCのprocess.cwdおよびリークされたfdsを介したコンテナブレイクアウト
- CVE-2024-45310: 空のファイルまたはディレクトリを作成するためのコンテナブレイクアウト
- CVE-2024-23651: Buildkit マウントキャッシュ競合
- CVE-2024-23652: Buildkit ビルド時コンテナ破棄における任意の削除
- CVE-2024-23653: Buildkit GRPC SecurityMode 特権チェック
これらのセキュリティ脆弱性を修正するには、影響を受けるDockerコンテナをパッチ適用済みのバージョンにアップグレードする必要があります。
注: 環境にどのバージョンのrunCがあるか不明な場合は、`docker version`を実行すると、出力の一部としてバージョンが表示されます。
重大度: 低 → 緊急
2. CVE-2025-9074: コンテナからのDocker Desktop Docker Engine APIへの未認証アクセス
Docker Engine APIは、Dockerデーモンと対話し、Dockerオブジェクトを管理するためのプログラムによるインターフェースを提供します。これは、Docker Desktopを含むすべてのDockerツールに存在します。
CVE-2025-9074は、Docker Desktopにおける深刻なサーバーサイドリクエストフォージェリ (SSRF)のような脆弱性です。この脆弱性により、「Enhanced Container Isolation」が有効になっている場合でも、コンテナはデフォルトで192.168.65.7:2375の設定済みDockerサブネットを介してDocker Engine APIにアクセスできます。また、「Expose daemon on tcp://localhost:2375 without TLS」オプションが有効になっているかどうかにかかわらず発生します。
CVE-2025-9074は、macOSおよびWindowsマシンのみに影響を与えます。DockerのようなほとんどのプロダクションシステムはLinux上で動作しますが、一部ではWindows Serverを使用している場合もあります（特にWindowsコンテナの使用が必要な場合）。
攻撃者は、以下のわずか3行のPythonコードでこのCVEをエクスプロイトできます。
The code above connects to the Docker daemon via TCP socket and runs a new Alpine container that creates a file exploit and mounts it to the host directory /Users/<username>. With that, when the container writes to the /mnt/exploit file, it writes to host /Users/<username>/exploit.
攻撃者はスクリプトを改変し、Dockerエンジンができるあらゆることを実行できます。これには、他のコンテナの制御、新規作成、イメージの管理などが含まれます。
macOSまたはWindowsでDocker Desktopを使用している場合は、この脆弱性がバージョン4.44.3で修正されているため、最新バージョンにアップデートしてください。
深刻度：クリティカル
3. CVE-2022-0847: Dirty pipe (Linux Kernel Escape)
CVE-2022-0847 Linuxカーネルの脆弱性は、カーネルのパイプコードにおけるpipe_buffer.flagsロジックの欠陥に起因し、悪意のあるアクターが読み取り専用ファイルに書き込み、O_RDONLYやimmutableなどの保護をバイパスすることを可能にします。その後、特権を昇格させることができます。
これはコンテナ固有の脆弱性ではありませんが、特権のないLinuxコンテナ内から使用して、ホスト上の/usr/bin/sudoのようなバイナリを上書きしたり、バックドアを注入したり、エクスプロイトの連鎖に利用したりすることができます。
この脆弱性に対する唯一の既知の修正方法は、Linuxホストをパッチ適用済みのKernelバージョンにアップグレードすることです。
重大度: 高
4. 安全でないベースイメージ
ベースイメージは、構築するすべてのコンテナの基盤であり、それらが脆弱であれば、アプリケーションも脆弱になります。残念ながら、コンテナを作成する際、多くのチームは ubuntu:latest や node:alpine のようなイメージタグが「動くターゲット」（moving targets）であることに気づかずに使用しています。
コンテナが今日使用する最新のイメージは、明日使用するイメージとは異なる場合があります。これにより、予期せぬセキュリティ脆弱性が導入される可能性があります。
この脆弱性を軽減するには、latestのようなタグを使用する代わりに、特定の信頼できるバージョン（例：FROM debian:bullseye-20230912）を指定してください。特定のイメージの信頼できるバージョンを使用する場合でも、Aikido securityのようなツールを使用して継続的にスキャンし、CVEやAutoFixの脆弱性を検出することを忘れないでください。
環境に導入される前に脆弱性を修正するため、コンテナレジストリ内のイメージもスキャンする必要があります。Aikidoは、Docker HubやHarborといったコンテナレジストリ内のイメージを統合してスキャンすることも可能です。
深刻度：低 → 致命的（コンテナイメージと使用状況による）
5. 無制限のDockerソケットアクセス
通常 `(/var/run/docker.sock)` にあるDockerソケットをコンテナにマウントすることは、コンテナ化された環境において最も危険な誤設定の一つです。これにより、コンテナはDocker Engine APIへの完全なアクセス権を得て、ホスト全体を制御できるようになります。これは本質的に悪いことではありませんが、単一の悪意のあるコンテナが、攻撃者にホスト全体の制御を許すことになりかねません。
チームは、「Docker-in-Docker」ビルドや監視ツールがコンテナを管理できるように、Dockerソケットをマウントすることがありますが、これはほとんどの場合、危険な近道です。
この脆弱性を軽減するには、Dockerソケットをコンテナにマウントしてはなりません。Docker-in-Docker機能が必要な場合は、rootless Docker、gVisor、またはKata Containersを使用して、厳密に管理されたビルド環境で隔離する必要があります。
Kubernetesを使用している場合、コンテナがDockerソケットのようなホストレベルのリソースにアクセスするのをブロックするために、Pod Security Standardsまたはアドミッションポリシーを適用すべきです。
重大度: 緊急
6. CVE-2025-23266: NVIDIA AIの脆弱性（GPUアクセス欠陥）
AIとMLは、この1年間で最も話題になったテーマです。これは、AIとMLが私たちの働き方や生活全般を変化させたためです。
CVE-2025-23266は、NVIDIA Container ToolkitおよびGPU Operatorに影響を与えるコンテナエスケープの脆弱性であり、GPUアクセラレーションコンテナの構築と実行を可能にします。
NVIDIA Container Toolkitは、GPUアクセス用にコンテナを構成するために、OCI (Open Container Initiative)フック（カスタムスクリプトまたはバイナリ）を使用します。これらのフックの1つであるenable-cuda-compatは、コンテナから環境変数を継承します。これにより、攻撃者はLD_PRELOADを悪意のある共有ライブラリを参照するように設定する悪意のあるイメージを作成する機会を得ます。
特権フックが実行されると、ライブラリはコンテナのサンドボックス外でホスト上にロードされ、結果として攻撃者にノードへのルートアクセスを付与します。
マルチテナントGPUクラスターでは、これはテナント間のデータ漏洩とノード侵害という重大なリスクを生み出します。
NVIDIAは両コンポーネントのパッチ適用済みバージョンをリリースしました。Toolkit v1.17.8およびGPU Operator 25.3.1へのアップグレード、またはオプションのフックを無効にすることで、脆弱性が軽減されます。
重大度: 重要
7. 露呈したシークレット
2025年IBMデータ侵害コストレポートによると、侵害された認証情報によって引き起こされたデータ侵害は、特定と封じ込めに最も時間がかかりました。データ侵害の平均コストが440万ドルであるため、組織はシークレットの漏洩を許容することはできません。
しかし、これらは依然として開発者が犯す最も一般的な間違いの1つです。これらのシークレットには、APIキー、パスワード、暗号化キー、秘密鍵などの機密性の高い認証情報が含まれており、攻撃者が機密データにアクセスしたり盗んだりする可能性があります。
開発者はDockerコンテナ内でシークレットを漏洩させる可能性があります。その方法は以下の通りです。
- Dockerfile (ENVまたはARG命令)
- イメージレイヤーにコピーされた.envファイルなど。
恐ろしいことに、コンテナが削除された後でも、イメージがまだ存在する場合（またはレジストリにプッシュされている場合）、シークレットにアクセス可能なままになる可能性があります。
組織がシークレットを漏洩している可能性は高いです。しかし、今すぐそれについて何ができるでしょうか？
そう、可能ですし、そうすべきです：
- アクティブなシークレットを見つけて、その後
- 新たな問題が本番環境に到達するのを防ぎます。
また、漏洩したシークレットの潜在的なリスクを評価するのに役立つライブシークレット検出機能を提供するソリューションもあります。
深刻度：高
8. コンテナ特権の脆弱性
前述の通り、コンテナをrootユーザーとして実行すべきではありません。これは自動的にホストへのアクセスを与えるものではありませんが、CVE-2022-0492のような他の脆弱性や、ボリュームマウントおよびケーパビリティの誤設定と組み合わせると、ブレイクアウトのリスクを大幅に高めます。
コンテナをrootユーザーとして実行する以外にも、特権を介してコンテナが脆弱になる他の方法があります。これは、コンテナを自動的に作成、変更、削除するKubernetesのようなコンテナオーケストレーターを使用する場合に特に当てはまります。
CVE-2023-2640およびCVE-2023-32629を使用すると、攻撃者はボリュームマウントを持つ非root特権コンテナを利用して権限を昇格させることができます。
Kubernetesでは、コンテナの権限とアクセス制御設定を定義するためにSecurity Contextを使用します。
上記のセキュリティコンテキストでは：
- runAsNonRoot: true: コンテナがUID 0で起動しないことを保証します。
- runAsUser: 1000: コンテナを非ルートユーザーとして明示的に実行します。
- allowPrivilegeEscalation: false: setuidやその他の昇格をブロックします。
- capabilities.drop: [ALL]: デフォルトですべてのLinuxケーパビリティを削除します
コンテナの特権とアクセスを管理するには、アプリケーションの動作を理解する必要があります。例えば、ディスクへの書き込みを行わない場合、関連するボリュームは読み取り専用としてマウントすべきであり、これにより攻撃対象領域をさらに削減できます。
コンテナの権限昇格の脆弱性およびそれらから保護する方法に関するガイドをお読みください。
重大度: 高 → 緊急
9. gh0stEdit: レイヤーベースのアクセス脆弱性
Dockerイメージは、エンドユーザーが実行する前にイメージの内容を明確に評価し、確認できるように設計されています。
しかし、gh0stEditの場合、その可視性は問題になりません。
正式なCVEではありませんが、gh0stEdit（研究者によって名付けられた名称）は、攻撃者がDockerイメージ（Docker Content Trustで署名されている場合でも）を、イメージ署名を破壊したり、静的/動的スキャンによる検出を回避したりして操作できるという、新しい脆弱性を説明しています。
図1: Dockerイメージの整合性バイパス: レイヤーは変更されたが、マニフェストは変更されていない。 出典（Hackernoon）
この操作は、Dockerがマニフェスト（イメージレイヤーとそのダイジェストをリストするレシピ）に焦点を当てており、各レイヤー内の個々のファイルには焦点を当てていないため、可能です。
攻撃者が悪意のあるスクリプトをレイヤーに注入した場合、コンテナはDockerfile、ビルドプロセス、レジストリチェックをバイパスして実行されます。これにより、システム全体に静かに拡散する可能性があります。
gh0stEditに対する修正と防御には、以下のようないくつかのステップが含まれます。
- 信頼できるソースからコンテナイメージを常に再構築する
- cosignのようなツールによるコンテナイメージの署名と検証
- Aikidoのようなツールによる脆弱性およびコンテンツスキャンは、カスタムルールでオープンソーススキャナーを補完し、ギャップを埋めてセキュリティ上の欠陥を明らかにします。
- アドミッションコントローラーを使用して、署名されていない、またはスキャンされていないイメージがクラスター内で実行されるのを防ぎます。
重大度: 低 → 致命的（コンテナイメージと攻撃対象領域による）
レジリエントなDockerセキュリティポスチャの構築
本記事で考察したように、runCコンテナブレイクアウト、未スキャンベースイメージ、露出したシークレット、過剰な特権などの脆弱性は、環境全体を静かに蝕む可能性があります。
堅牢なDockerセキュリティ体制を実装することは、チェックボックス形式のスキャンを超え、コンテキストを考慮し、ランタイムを認識し、ポリシーに基づいた防御へと移行し、脆弱性を自動的に発見・修正することを意味します。
At Aikidoでは、Trivy、Syft、Grypeのような確立されたオープンソースプロジェクトを高く評価しています。しかし、それらを単独で使用することが、特に優れた開発者体験ではないことも経験から知っています。
Aikidoは、カスタムルールでこれらのプロジェクトを強化し、ギャップを埋め、そうでなければ見つけられなかったであろうセキュリティ上の欠陥を明らかにします。さまざまなオープンソースツールを連結するのとは異なり、Aikidoは、スキャン用スクリプトの作成やCI/CDでのカスタムジョブの作成から解放します。
Dockerセキュリティについては常に学ぶべきことがあります。Dockerを安全に保つことに関するさらなる疑問に答えるために、脆弱性を意識する開発者向けの実践的なDockerセキュリティチェックリストをご覧ください。
続きを読む:
クラウドセキュリティの脆弱性トップ7
すべてのチームが知っておくべきWebアプリケーションセキュリティの脆弱性トップ10
Kubernetesセキュリティの脆弱性と設定ミス トップ9
最新のアプリケーションで発見されたコードセキュリティの脆弱性トップ
開発者が避けるべきPythonセキュリティの脆弱性トップ10
最新のWebアプリにおけるJavaScriptセキュリティの脆弱性トップ
ソフトウェアサプライチェーンセキュリティの脆弱性トップ9を解説
