Dockerコンテナのセキュリティ脆弱性トップ9

最後にDockerコンテナイメージの内部を調べたのはいつですか？なぜなら、ここに醜い真実があるからです：コンテナを構成するすべてのFROM命令、コピーされたバイナリ、インストールされたパッケージが、潜在的な攻撃ベクトルとなり得るのです。 

つまり、コンテナイメージのレイヤーやビルド時の依存関係を定期的に点検していない場合、自覚している以上に多くのリスクを引き継いでいる可能性が高いということです。

CVE（共通脆弱性情報）、不安全なベースイメージ、ハードコードされたシークレット、過剰な権限付与は、攻撃者が侵入する手段の一部に過ぎません。これは御社のような組織にとって懸念すべき問題です。

実際、 レッドハットの「2024年コンテナセキュリティの現状」レポート（DevOps、エンジニアリング、セキュリティの専門家600名を対象に実施 ）によると、チームのほぼ半数（42%）がコンテナセキュリティが「夜も眠れないほど心配」だと認めている。 

コンテナランタイムの脆弱性から重要なGPUワークロードに影響するCVEまで、本記事では最も重要でありながら見過ごされがちなDockerコンテナの脆弱性9つを解説します。

Dockerコンテナの脆弱性とは何ですか？

Dockerコンテナの脆弱性とは、コンテナイメージ、ランタイム、またはその基盤インフラストラクチャ内の弱点、設定ミス、欠陥のことで、攻撃者がセキュリティ侵害に悪用できるものです。これには、既知のCVEだけでなく、安全でないデフォルト設定、漏洩したシークレット、過剰な権限といった見落とされがちな問題も含まれます。

Dockerコンテナが開発者にとって非常に強力である理由であるその速度と移植性は、セキュリティチームにとっては悪夢となり得る。例えば、最新のタグでイメージをプルしたり、コンテナを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バイナリを上書きすることで、ホストのrootアクセス権を侵害することが可能でした。 

この脆弱性は古いもの（2025年時点で6年経過）ですが、多くのチームが依然として影響を受けています。特に、パッチ未適用のDocker/runCやレガシーバージョン、カスタムまたはフォークされたランタイムなどを使用する環境では顕著です。 

CVE-2019-5736の脆弱性における重要なニュアンスは、コンテナプロセスがrootユーザーとして実行されている必要がある点です。仮にコンテナが非rootユーザー（例：DockerfileでUSER 1000を指定、またはKubernetesでsecurityContext.runAsNonRoot: trueを設定）として実行されていた場合、 この場合、攻撃者は必要な権限を欠いているため、上書きパスをトリガーできません。これが、コンテナをrootユーザーとして実行しないことが重要な理由です。  

2019年以降、runCおよびDockerコンテナの脱走脆弱性がさらに表面化しており、その深刻度は低いものから重大なものまで様々である：

• CVE-2024-21626: runCプロセスによるコンテナ脱走（cwdおよび漏洩したファイル記述子） 
• 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）に類似した脆弱性です。この脆弱性により、コンテナは「強化されたコンテナ分離」が有効な場合でも、デフォルトで設定されたDockerサブネット（192.168.65.7:2375）経由でDocker Engine APIにアクセスできます。 また、「TLSなしでtcp://localhost:2375上にデーモンを公開する」オプションの有効/無効にかかわらず発生します。

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: ダーティパイプ (Linuxカーネルエスケープ)

CVE-2022-0847Linuxカーネル脆弱性は、カーネルのパイプコードにおけるpipe_buffer.flagsロジックの欠陥に起因する。これにより悪意のある攻撃者は、O_RDONLYやimmutableといった保護機能を迂回して読み取り専用ファイルへの書き込みが可能となり、権限昇格を実行できる。 

コンテナ固有の脆弱性ではないものの、非特権Linuxコンテナ内から利用することで、ホスト上の/usr/bin/sudoなどのバイナリを上書きしたり、バックドアを注入したり、エクスプロイトの連鎖攻撃に利用することが可能です。

この脆弱性に対する唯一の既知の修正策は、Linuxホストをパッチ適用済みカーネルバージョンにアップグレードすることです。 

深刻度: 高  

4. 不安全なベースイメージ

ベースイメージは構築するすべてのコンテナの基盤であり、脆弱性があればアプリケーションも同様に脆弱です。残念ながら、コンテナ作成時に多くのチームが ubuntu:latest や node:alpine といったイメージタグを依然として使用していますが、これらのタグが流動的であることに気づいていません。 

コンテナが今日使用する最新のイメージは、明日使用するイメージと異なる可能性があります。これにより予期せぬセキュリティ上の脆弱性が生じる恐れがあります。  

この脆弱性を軽減するには、latestのようなタグを使用する代わりに、特定の信頼できるバージョン（例：FROM debian:bullseye-20230912）を指定してください。また、特定のイメージの信頼できるバージョンを使用する際は、Aikido ツールを使用して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を使用する場合、Pod Security Standardsまたはアドミッションポリシーを適用し、コンテナがDockerソケットなどのホストレベルリソースにアクセスできないようにブロックする必要があります。 

深刻度: 重大

6. CVE-2025-23266: NVIDIA AI 脆弱性 (GPU アクセス欠陥)

この1年、私たちが話題にしてきたのはAIと機械学習ばかりです。なぜなら、それらが私たちの働き方や生活全般を変えたからです。 

CVE-2025-23266は、NVIDIA Container ToolkitおよびGPU Operatorに影響を与えるコンテナエスケープ脆弱性であり、これによりGPUアクセラレーション対応コンテナの構築と実行が可能となります。

NVIDIAコンテナツールキットは、GPUアクセス用にコンテナを設定するため、 OCI（Open Container Initiative）フック（カスタムスクリプトまたはバイナリ）を利用します。これらのフックの一つであるenable-cuda-compatは、コンテナから環境変数を継承します。これにより、攻撃者が LD_PRELOADを不正な共有ライブラリを参照するように設定した悪意のあるイメージを作成する可能性が生じます。  

特権フックが実行されると、ライブラリはコンテナのサンドボックス外であるホスト上でロードされ、攻撃者にノード上のrootアクセス権を実質的に付与する。 

マルチテナントGPUクラスタでは、これによりテナント間のデータ漏洩やノード侵害の深刻なリスクが生じる。

NVIDIAは両コンポーネントの修正版を公開しました。Toolkit v1.17.8 および GPU Operator 25.3.1 へのアップグレード、またはオプションのフックを無効化することで、この脆弱性を軽減できます。

深刻度: 重要  

7. 暴露された秘密

の「2025年IBMデータ侵害コストレポート」によると、認証情報の侵害によるデータ侵害は、特定と封じ込めに最も長い時間を要した。データ侵害の平均コストは440万ドルに達しており、組織は機密情報の流出を許容できない。 

しかし、これらは依然として開発者が犯す最も一般的なミスの一つです。これらの機密情報には、APIキー、パスワード、暗号化キー、秘密鍵などの機微な認証情報が含まれており、攻撃者が機密データにアクセスしたり盗んだりすることを可能にする可能性があります。

開発者はDockerコンテナ内で以下の方法により機密情報を漏洩させる可能性があります：

• Dockerfile（ENVまたはARGディレクティブ）
• .envファイルをイメージレイヤーにコピーするなど 

恐ろしいのは、コンテナが削除された後でも、イメージがまだ存在している場合（またはレジストリにプッシュされている場合）、シークレットがアクセス可能な状態のまま残る可能性があることです。

組織が機密情報を漏洩している可能性は高い。しかし、今すぐに何ができるだろうか？ 

ええ、できるし、すべきです：

• アクティブなシークレットをすべて見つけた後、 
• 新たなものが本番環境に到達するのを防ぐ。 

また、公開されたシークレットの潜在的なリスクを評価するのに役立つ、ライブシークレット検出機能を提供するソリューションもいくつか存在します。

深刻度: 高

8. コンテナ特権の脆弱性

前述の通り、コンテナをrootユーザーとして実行すべきではありません。これ自体は自動的にホストへのアクセス権を与えるものではありませんが、 CVE-2022-0492のような他の脆弱性や、ボリュームマウントや機能設定の誤りと組み合わさると、ブレイクアウトのリスクを大幅に高めます。 

コンテナをrootユーザーとして実行すること以外にも、権限を介してコンテナが脆弱になる方法は存在する。これは特に、コンテナオーケストレーター（例：Kubernetes）を使用する場合に当てはまる。Kubernetesはコンテナの作成、変更、削除を自動的に行うためである。 

CVE-2023-2640 および CVE-2023-32629 により、攻撃者はボリュームマウントされた非 root 特権コンテナを利用して特権を昇格させることが可能です。 

Kubernetesでは、セキュリティコンテキストを使用してコンテナの権限とアクセス制御設定を定義します。

上記のセキュリティコンテキストにおいて： 

• runAsNonRoot: true: コンテナがUID 0として起動しないことを保証します
• runAsUser: 1000: コンテナを明示的に非rootユーザーとして実行する
• 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セキュリティ態勢を実装するには、チェックボックス式のスキャンから脱却し、コンテキストを認識し、実行環境を意識した、ポリシー駆動型の防御へと移行する必要があります。これにより、脆弱性を自動的に発見し修正することが可能となります。 

Aikidoでは、 Trivy、 Syft、 Grypeといった確立されたオープンソースプロジェクトを高く評価しています。しかし経験上、それらを単独で使用することは開発者にとって特に良い体験とは言えないことも理解しています。 

Aikido カスタムルールでこれらのプロジェクトをAikido 、ギャップを埋め、他の方法では発見できないセキュリティ上の欠陥を明らかにします。様々なオープンソースツールを組み合わせるのと異なり、Aikido スキャンスクリプトの作成やCI/CD環境でのカスタムジョブ作成の必要からAikido 。

Dockerのセキュリティについては、学ぶべきことが常にあります。Dockerの安全性を維持するための疑問をさらに解消するには、脆弱性に敏感な開発者向けの「 無駄のないDockerセキュリティチェックリスト」をご覧ください。