Docker Engine CVE-2026-34040 — 過大HTTPリクエストでAuthZプラグインを無効化、特権コンテナ経由でホスト掌握

この記事は約12分で読めます。

Docker Engineの認可プラグイン(AuthZプラグイン)を、1MBを超える過大なHTTPリクエストボディで無効化できる脆弱性CVE-2026-34040が公開されました。Cyera Research Labsが2026年3月24日にDockerへ報告し、翌25日にDocker Engine 29.3.1で修正版がリリースされています。本稿では、AuthZプラグインに依存して権限境界を引いている運用現場の視点から、5年間にわたって2度の修正をすり抜けてきた本脆弱性の構造、攻撃チェーン、そしてAIエージェント時代における新たな悪用経路までを実務観点で整理します。

脆弱性の概要

項目 内容
CVE ID CVE-2026-34040
GHSA ID GHSA-x744-4wpc-v9h2
CVSS v3.1スコア 8.8 HIGH(CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
CWE分類 GHSA本文では未記載。NVDはCWE-288(Authentication Bypass Using an Alternate Path or Channel)を掲載。一方、Cyeraは本件をCWE-863(Incorrect Authorization)の系統と位置づけています
影響対象 Docker Engine 29.3.1未満
修正バージョン Docker Engine 29.3.1。Docker Desktopは4.66.1以降でDocker Engine 29.3.1を同梱します
公開日 2026年3月25日(GHSA)/ 3月26〜27日(NVD登録、Docker Desktop修正版リリース)
発見者 Cyera Research Labs(Vladimir Tokarev氏)、Oleh Konko氏(@1seal)、Cody氏、Asim Viladi Oglu Manizada氏が独立に報告。Docker側の修正担当はvvoland氏
悪用観測 2026年4月8日時点で、確認した一次ソースおよび主要報道に野生悪用報告は見当たりません

本脆弱性は2024年7月に公開されたCVE-2024-41110(CVSS 10.0)の修正が不完全であったことに起因します。CVE-2024-41110は「ボディ長ゼロ」のリクエストでAuthZプラグインを迂回する問題で、Docker Engine v27.1.1で修正されましたが、今回新たに「ボディ長が1MBを超える場合」も同様にAuthZプラグインを迂回してしまうことが判明しました。

影響を受ける前提

Docker公式アドバイザリ(GHSA-x744-4wpc-v9h2)は、影響範囲について明確に限定しています。「AuthZプラグインを使用していない場合、本脆弱性の影響は受けません」と記載されており、影響対象は「リクエストボディの内容を検査してアクセス制御判断を行うAuthZプラグインに依存している環境」に限られます。

具体的には、Open Policy Agent(OPA)、Prisma Cloud、Casbin、その他カスタムAuthZプラグインを使用してDocker APIの操作を制御している環境が対象となります。これらはエンタープライズ環境でDockerホストへのアクセス制御を強化するために広く採用されているコンポーネントです。

また、CVSSのAttack Vectorは「Local」、Privileges Requiredは「Low」となっており、攻撃者は事前にDocker APIへの何らかのアクセス権を持っている必要があります。インターネット越しに無認証で悪用できる脆弱性ではない点を、影響評価時に押さえておく必要があります。

攻撃の仕組み — 1MBの過大ボディで認可判定をすり抜ける

Cyera Researchの解析によると、攻撃チェーンは以下の4ステップで構成されます。

  1. 過大リクエストの送信:攻撃者は通常のコンテナ作成リクエストにダミーのパディングフィールドを加え、ボディ長を1MBを超える状態にしてDocker APIへ送信します。
  2. ミドルウェアによるボディの破棄:Docker daemonのミドルウェアはサイズ上限チェックでボディを破棄しますが、エラーで止めるのではなく、AuthZプラグインへはボディが空の状態でリクエストを転送してしまいます。
  3. AuthZプラグインの誤った許可:プラグイン側はリクエストボディに検査対象の内容が見えないため、ブロックすべき要素を検出できず、リクエストを許可します。OPA、Prisma Cloud、Casbinなどボディ検査型のプラグインはいずれも同様に迂回されます。
  4. 特権コンテナの作成とホスト掌握:daemonは破棄されていない完全なボディを処理してリクエストを実行し、特権コンテナを作成します。攻撃者はホストファイルシステムをマウントし、AWSクレデンシャル、SSH鍵、kubeconfig等を抽出できます。そこからクラウドアカウント、Kubernetesクラスタ、本番サーバーへの侵入経路が広がります。

Cyeraの報告では、攻撃自体はレース条件や複雑な連鎖を必要とせず、パディング付きの単一HTTPリクエストで成立する点が強調されています。一方でDocker側のGHSAは「悪用の基底尤度は低い」と評価しており、両者の表現には差があります(後述)。

5年間潜伏した認可バイパスの経緯

本脆弱性は、2019年に一度修正されたAuthZプラグインバイパスの「再発」であることが、Cyeraの開示タイムラインから読み取れます。

時期 出来事
2019年1月 Docker v18.09.1で当初のAuthZバイパスを修正
2019〜2024年 修正がコードベース全体に引き継がれず、回帰がコードベース内に潜伏
2024年7月 CVE-2024-41110(CVSS 10.0)公開。ボディ長ゼロのリクエストによる迂回をDocker v27.1.1で修正
2026年3月24日 Cyera ResearchがCVE-2026-34040をDockerへ報告。CVE-2024-41110の修正がボディ長1MB超のケースを処理できていないことを発見
2026年3月25日 Docker Engine 29.3.1リリース、GHSA-x744-4wpc-v9h2公開
2026年3月26〜27日 Docker Desktop 4.66.1リリース、CVE-2026-34040がNVDに登録

Cyeraは本件を「OWASPが2003年から指摘してきたCWE-863(Incorrect Authorization)の系統的なバグ」と位置づけており、新規のゼロデイというよりも、基盤的な脆弱性クラスが現代のクリティカルインフラに残り続けている事例として捉えるべきだと指摘しています。

評価の差異 — Docker公式とCyeraで温度差がある

本脆弱性の悪用しやすさについて、Docker公式アドバイザリと発見者であるCyeraの間には明確な評価差があります。実務判断においてはこの両論を踏まえる必要があります。

  • Docker公式(GHSA-x744-4wpc-v9h2):「本脆弱性が悪用される基底尤度は低い(The base likelihood of this being exploited is low)」と明記
  • Cyera Research:「悪用は単純かつ実用的(High and simple)。レース条件やタイミング依存はなく、TCP/TLS越しに動作し、エンタープライズ環境、CI/CD、管理プラットフォームに広く適用可能。OPA、Prisma Cloud、Casbin、すべてのカスタムAuthZプラグインを等しく迂回する」

この差異は、Docker側が「攻撃にはDocker APIへの事前アクセスとAuthZプラグインの利用という2つの前提が必要」と見ているのに対し、Cyera側は「その前提さえ満たせば技術的ハードルはほぼゼロ」という観点で評価していることに起因すると考えられます。AuthZプラグインを導入している環境においては、Cyera側の評価を踏まえて優先度を高く扱うのが妥当と言えます。

AIエージェント時代の新たな観点

Cyeraの解析で特に注目される論点は、AIコーディングエージェントが本脆弱性を介在物として悪用するシナリオが提示されている点です。

第一のシナリオは、Dockerサンドボックス内で動作するAIコーディングエージェント(例として記事#29で取り上げたOpenClawなど)が、開発者の通常ワークフローの一環として悪意あるGitHubリポジトリにアクセスした際、リポジトリ内に仕込まれたプロンプトインジェクションを実行してしまうケースです。インジェクションされたコードがCVE-2026-34040を悪用し、サンドボックスを脱出して特権コンテナを作成、ホストファイルシステムをマウントするという連鎖が成立します。

第二のシナリオはより示唆的です。Cyeraは、AIエージェントが正当なデバッグ作業(例:Kubernetesクラスタのout-of-memoryトラブルシューティング)の中で、AuthZプラグインに拒否されたマウントリクエストへの対応を試みるうちに、訓練データに含まれていたCVE-2024-41110の知識を頼りにサイズ境界の存在に気づき、自律的にパディング付きHTTPリクエストを構築して迂回してしまう可能性を指摘しています。Tokarev氏は「CVE-2026-34040は悪用コードも特権も特殊ツールも必要としません。Docker APIドキュメントを読めるエージェントなら誰でも構築できる単一HTTPリクエストです」と述べています。

これは、Trivyサプライチェーン攻撃(記事#21)やOpenClaw権限昇格(記事#29)、Flowise RCE(記事#30)と続いてきたAIエージェントビルダー脆弱性シリーズに、新たな「コンテナランタイム層の認可境界」という観点を追加するものです。AIエージェントが副作用としてセキュリティ境界を越える可能性を、設計段階でどう抑制するかという問いを突きつけています。

確認手順と対処

Cyeraが推奨する確認・対処フローは以下の通りです。

  1. Docker Engineバージョンの確認docker version --format '{{.Server.Version}}' を実行し、29.3.1未満であれば脆弱性の影響を受けます。
  2. AuthZプラグインの利用有無の確認docker info --format '{{.Plugins.Authorization}}' を実行し、プラグイン名が返ってくる場合は影響対象です。
  3. 悪用痕跡の調査:daemonログを journalctl -u docker | grep "Request body is larger than" で検索し、過大ボディのリクエスト痕跡がないかを確認します。
  4. AIエージェントのDocker APIアクセス権の棚卸し:自動化システムがDocker APIへどの範囲のアクセスを持っているかを再確認し、必要最小限に絞ります。
  5. 機密データを保持するDockerホストの特定:本番クレデンシャルや規制対象データを扱うホストを優先的にパッチします。

即時パッチが難しい場合の緩和策

Docker公式およびCyeraが提示している一時的な緩和策は次の通りです。

  • リクエストボディ検査型のAuthZプラグインの一時停止:アクセス制御判断にリクエストボディの中身を必要とするプラグインの利用を一時的に避けます。
  • Docker APIアクセスの最小権限化:信頼できる主体のみにアクセスを限定します。
  • リバースプロキシでのボディサイズ制限:APIゲートウェイで512KBのボディサイズ上限を設定すると、過大ボディによる迂回試行をブロックできます。
  • ルートレスモードの利用:Tokarev氏は「ルートレスモードでは、特権コンテナの『root』であってもホスト側では非特権UIDにマップされる。被害範囲は『ホスト完全掌握』から『非特権ユーザー権限の侵害』まで縮小する」と説明しています。完全なルートレス化が難しい環境では --userns-remap による同様のUIDマッピングも有効です。

実務への含意

本脆弱性は、AuthZプラグインという「権限境界の最後の防波堤」を、リクエストボディのサイズという周辺的な要因で無効化できる点に本質があります。OPAやPrisma Cloudのような商用・OSSのAuthZプラグインを導入していることがそのまま安全を保証するわけではなく、ミドルウェア層との整合性まで含めて検証されていなければ、認可の判断そのものがバイパスされてしまうという構造的問題が顕在化しました。

同時に、5年間にわたって2度の修正がすり抜けたという経緯は、回帰テストや修正の適用範囲が、コードベース全体の同種パターンに対して横展開されていなかったことを示唆します。CVE-2024-41110の修正時点で「ボディ長ゼロ」だけでなく「ボディ長が極端に大きい場合」も含めて検証されていれば、今回の再発は避けられた可能性があります。

Docker EngineおよびDocker Desktopは即座に最新版へ更新するのが最優先です。AuthZプラグインを導入している環境では、Cyeraが提示するリバースプロキシでのボディサイズ制限や、ルートレスモードへの移行を、パッチ適用と並行して検討する価値があります。AIエージェントにDocker APIアクセスを与えている場合は、その権限範囲を改めて見直し、サンドボックスとホスト境界の前提が崩れた場合の被害想定を再評価することが求められます。

ソース

一次ソース

参考情報

コメント

タイトルとURLをコピーしました