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リクエストが1MBを超える場合、Dockerのミドルウェアは認可プラグインに転送される前にリクエストボディをサイレンシャスに切り詰めます。
それにもかかわらず、Dockerデーモンは完全で変更されていないリクエストの処理を続行し、セキュリティ評価対象と実際に実行されるもの間に重大な矛盾を生じさせます。
この矛盾により危険な不一致が生じます。認可プラグインは空のリクエストのように見えるものを評価して承認しますが、デーモンは完全なペイロードを実行します。
攻撃者は、リクエストを1MBしきい値を超える分まで埋め込むことでこの動作を利用でき、セキュリティ実施を効果的に除去できます。
その結果、特権コンテナを作成し、ホストファイルシステムをマウントし、クラウド認証情報、SSHキー、またはKubernetes設定ファイルなどの機密データへのアクセスを得ることができます。
攻撃自体はシンプルで信頼性が高いです。単一の細工されたHTTPリクエストのみが必要であり、レース条件、複雑なチェーニング、または高度な手法に依存しません。
標準Docker APIの動作を活用しているため、悪用は実用的で、実際の環境での検出が困難です。
過去のDocker脆弱性との関連性
特に注目すべきは、この脆弱性は以前公開された問題であるCVE-2024-41110に基づいており、ゼロ長リクエストボディに関連する同様のバイパスに対処していました。
その修正は1つのエッジケースを解決しましたが、サイズの大きいペイロードを考慮できず、上限条件を悪用可能なままにしました。
Dockerはその後、この問題に対処するための修正をリリースしました。
Dockerリスクを軽減する方法
組織はこの脆弱性からのリスクを軽減するために層状のアプローチを取る必要があります。パッチに加えて、いくつかの構成、監視、アクセス制御措置は全体的なコンテナセキュリティを強化するのに役立ちます。
- パッチ：Docker EngineおよびDocker Desktopの最新バージョンにアップグレードして、認可バイパスを排除します。
- ネットワークセグメンテーション、ファイアウォール、強力な認証制御を通じてDocker APIアクセスを制限およびセキュアにします。
- 認可プラグイン使用状況について環境を監査し、可能な場合はそれらへの依存を減らすか、上流で制御を実施します。
- 監視：Dockerログをレビューして悪用の兆候がないか監視し、特権コンテナと異常な動作に対するランタイム検出をデプロイします。
- リバースプロキシリクエストサイズ制限やコンテナソケットプロキシなどの代替制御を適用します。パッチが遅延されている場合。
- rootlessDocker を使用し、最小権限を実施し、ホストに保存された機密データを最小化することで、ホストおよびコンテナの構成をハード化します。
- インシデント対応計画をテストし、インシデント対応計画および攻撃シミュレーションツールをコンテナ悪用およびホスト侵害のシナリオで使用します。
これらの測定値を組み合わせることで、組織は悪用に対するレジリエンスを構築し、侵害が発生した場合の潜在的な被害を最小化するのに役立ちます。
AI駆動環境における新興リスク
この脆弱性は、システムがデータを処理する方法の小さな矛盾がいかに信頼性の高いセキュリティ制御を弱める可能性があるかを示しています。
また、自動化されたシステムとAI駆動ツールがインフラストラクチャとのやり取りを増やすにつれて、リスクがどのように出現する可能性があるかのシフトを反映しています。
場合によっては、これらのツールは、日常的なタスクを完了しようとしながら、弱点を特定して意図せず悪用し、従来の脅威主体を超えて潜在的な露出の範囲を拡大する可能性があります。
これらの進化するリスクは、ゼロトラストソリューションの必要性を強化します。これは暗黙の信頼がなく、システムとワークロード全体でのアクセスを継続的に検証します。
