Docker Engineの脆弱性により、攻撃者は認可制御を回避し、ホストシステムへの完全なアクセス権を取得する可能性がある。
Cyeraの研究者は、この脆弱性が、組織がコンテナポリシーを適用するために依存している中核的なセキュリティメカニズムに影響すると明らかにした。
「今回の調査は、基盤となるインフラの多くが、機密データや特権ワークフローに非常に近い場所で使われるようになった今も、古いタイプのバグを抱えていることを示している」と、Cyeraの研究者はeSecurityPlanetへのメールで述べた。
さらに、「これはDockerだけの問題ではないことも示している。企業が現在、AIエージェントやデータパイプライン、本番環境へのアクセスを任せているインフラで、OWASPに分類されるおなじみのバグが繰り返し見つかっている」と付け加えた。
CVE-2026-34040の内部
この脆弱性、CVE-2026-34040は、認可（AuthZ）プラグインを有効にしてDockerを実行しているあらゆる組織に影響する。これは、OPA、Prisma Cloud、カスタムポリシーなどのツールを使ってコンテナのセキュリティを適用する企業環境では一般的な構成だ。
Dockerはクラウドインフラや開発パイプラインで広く採用されているため、潜在的な影響範囲は大きい。
さらに、根本的な脆弱性は約10年間存在しており、Docker Engine 1.10までさかのぼるバージョンに影響する。
Dockerの認可制御
この脆弱性は、大まかに言えば、組織が実行時のポリシー適用に依存しているコンテナセキュリティの重要な層を弱体化させる。
認可プラグインはこのモデルの中心的な役割を担い、定義されたセキュリティルールに基づいてリクエストを評価し、承認または拒否する門番として機能する。
こうした制御は、特権コンテナの起動、機密性の高いホストファイルシステムのマウント、重要なシステムリソースへのアクセス許可などの高リスクな操作を防ぎ、攻撃対象領域を縮小することを目的としている。
しかし、この脆弱性により、アラートや明確な失敗の兆候を発生させることなく、こうした制御をひそかに回避できる。結果として、成熟したセキュリティプログラムにも盲点が生じる。
この脆弱性の仕組み
CVSSスコア8.8の認可バイパスに分類されるこの脆弱性は、DockerのアーキテクチャにおけるHTTPリクエストボディの処理の不整合に起因する。
APIリクエストが1 MBを超えると、Dockerのミドルウェアは認可プラグインに転送する前に、リクエストボディをひそかに切り詰める。
それにもかかわらず、Dockerデーモンは完全かつ変更されていないリクエストの処理を続けるため、セキュリティ評価の対象と最終的に実行される内容との間に重大な不整合が生じる。
この食い違いにより危険なミスマッチが生じる。認可プラグインは空に見えるリクエストを評価して承認する一方、デーモンは完全なペイロードを実行する。
攻撃者は、リクエストにデータを追加して1 MBのしきい値を超えさせることで、この挙動を悪用し、実質的にセキュリティ適用を取り除くことができる。
その結果、特権コンテナの作成、ホストファイルシステムのマウント、クラウド認証情報、SSHキー、Kubernetes設定ファイルなどの機密データへのアクセスが可能になる。
攻撃自体は単純で信頼性も高い。必要なのは細工したHTTPリクエスト1つだけで、競合状態や複雑な攻撃チェーン、高度な技術には依存しない。
標準的なDocker APIの挙動を利用するため、実環境での悪用は現実的で、検知も難しい。
過去のDocker脆弱性との関連
注目すべきことに、これは以前開示された問題、CVE-2024-41110に基づくもので、ゼロ長のリクエストボディに関わる同様のバイパスに対処していた。
この修正は1つのエッジケースを解決したものの、サイズ超過したペイロードには対応できず、上限側の条件が悪用可能なまま残った。
Dockerはその後、この問題に対処する修正をリリースした。
Dockerのリスクを低減する方法
組織は、この脆弱性によるリスクを低減するために、階層化されたアプローチを取るべきだ。パッチ適用に加え、構成、監視、アクセス制御に関する複数の対策によって、コンテナ全体のセキュリティを強化できる。
- パッチを適用しDocker Engineの最新バージョンにアップグレードするとともにDocker Desktopも更新して、認可バイパスを排除する。
- ネットワークのセグメンテーション、を通じてDocker APIへのアクセスを制限・保護し、ファイアウォールと強力な認証制御を導入する。
- 認可プラグインの使用状況を環境全体で監査し、可能な場合は依存を減らすか、上流で制御を適用する。
- 監視しDockerログを確認して悪用の兆候を捉え、特権コンテナや異常な挙動をランタイムで検知する。
- パッチ適用が遅れる場合は、リバースプロキシによるリクエストサイズ制限やコンテナソケットプロキシなどの代替制御を適用する。
- ホストとコンテナの構成を強化し、rootless Dockerを使用し、最小権限を徹底するとともに、ホストに保存する機密データを最小限に抑える。
- テストしインシデント対応計画を、攻撃シミュレーションツールを使って、コンテナの悪用やホスト侵害を想定したシナリオで検証する。
これらの対策を組み合わせることで、組織は悪用に対するレジリエンスを高め、侵害が発生した場合の影響範囲を最小限に抑えられる。
AI主導環境における新たなリスク
この脆弱性は、システムによるデータ処理の小さな不整合が、信頼性の高いセキュリティ制御を弱体化させる可能性を示している。
また、自動化システムやAI主導のツールがインフラと接する機会が増える中で、リスクの現れ方が変化していることも示している。
場合によっては、こうしたツールが定常的なタスクを完了しようとする過程で、弱点を特定し、意図せず悪用する可能性があり、従来の脅威アクターを超えて潜在的な曝露範囲が広がる。
こうした進化するリスクは、ゼロトラストソリューションを必要とする。これらは暗黙の信頼を置かず、システムやワークロード全体でアクセスを継続的に検証する。