技術 約6分で読めます

Docker Engine AuthZプラグインバイパスの不完全修正が再び悪用可能に（CVE-2026-34040）

セキュリティ CVE Docker コンテナ
いけさん目次

DockerのコンテナエンジンMobyに、認可プラグイン（Authorization Plugin、AuthZ）を迂回できる脆弱性CVE-2026-34040（CVSS 8.8）が公開された。発表は2026年3月30日。パッチ済みバージョンは29.3.1で、それ以前の全バージョンが影響を受ける。

この脆弱性は2024年7月に修正されたCVE-2024-41110（CVSS 10.0）のリグレッションだ。一方の端（ゼロバイト）を直したが、もう一方の端（1MBを超える場合）を塞いでいなかった。

AuthZプラグインとは

Dockerデーモンはデフォルトでは接続してきたクライアントのAPIリクエストをほぼそのまま処理する。エンタープライズ環境や多テナント構成では「どのユーザーがどのAPIを呼べるか」を細かく制御したいが、その用途のために設けられているのがAuthZプラグインだ。

仕組みとしては、DockerデーモンがAPIリクエストを受け取ったとき、実行前にプラグインへリクエストの内容（ヘッダー＋ボディ）を転送し、プラグインが許可か拒否かを返す形になっている。プラグイン側はリクエストボディの中身——たとえばコンテナ作成時のイメージ名や特権フラグ——を見て判断できる。

graph TD
    A[Dockerクライアント] -->|API リクエスト| B[Dockerデーモン]
    B -->|リクエスト転送| C[AuthZプラグイン]
    C -->|許可 or 拒否| B
    B -->|許可の場合| D[コンテナ操作実行]
    B -->|拒否の場合| E[403 Forbidden]

CVE-2024-41110の「ゼロ側」バイパス

今回の問題を理解するには先行するCVE-2024-41110から見る必要がある。

もともとDocker Engine v18.09.1（2019年1月）で、Content-Length: 0 のAPIリクエストを使ってAuthZプラグインを迂回できるバグが修正されていた。ところがその修正がv19.03以降に引き継がれず、バグが復活した状態になっていた。

技術的な核心は条件式 r.ContentLength > 0 にあった。Content-Lengthがゼロの場合、この条件は偽になり、ボディがプラグインへ転送されない。プラグインはボディ空のリクエストとして判断し許可を出すが、デーモン側は実際のリクエストボディを読み込んで処理してしまう。

POST /v1.45/containers/create HTTP/1.1
Content-Type: application/json
Content-Length: 0

{"Image":"ubuntu","HostConfig":{"Privileged":true}}

AuthZプラグインは「ボディが空のPOSTリクエスト」として評価するため、特権コンテナ作成の意図を検知できない。CVE-2024-41110はこの下限側（ゼロバイト）の問題を修正し、パッチがv23.0.15、v26.1.5、v27.1.1として2024年7月に配布された。

CVE-2026-34040の「上限側」バイパス

CVE-2024-41110の修正はゼロバイトのケースにのみ対処していた。今回のCVE-2026-34040は上限側の見落としを突く。

APIリクエストのボディが1MBを超えると、Dockerのミドルウェアはプラグインに転送する前にボディを無言でトランケート（切り捨て）する。しかしデーモン自身はトランケートされていない完全なリクエストを処理する。

graph TD
    A[攻撃者] -->|1MBを超えるAPIリクエスト送信| B[Dockerデーモン]
    B -->|ミドルウェアがボディをトランケート| C[AuthZプラグイン]
    C -->|切り捨て後の小さなボディを評価| D{"許可判断"}
    D -->|「空に見えるので」許可| E[デーモンに返却]
    B -->|完全なオリジナルリクエストを処理| F[特権コンテナ作成など]
    F --> G[ホストファイルシステムへのアクセス]
    F --> H[cloud credentials / SSH鍵の窃取]
    F --> I[Kubernetes設定ファイルの読み取り]

攻撃者はリクエストにパディングを付け足すだけで1MBの閾値を超えられる。攻撃チェーンの複雑さは最小限で、レースコンディションや多段チェーンを必要としない。eSecurity Planetは「単一のHTTPリクエストで完結し、実際の環境での検出も難しい」と評している。

CVSSベクトルは CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H（GitHub版8.8）。スコープ（S）が「変更あり（C）」なのは、コンテナの境界を越えてホストOSに影響が及ぶため。

この脆弱性が影響する条件

GitHubのアドバイザリ（GHSA-x744-4wpc-v9h2）は明確に書いている。「AuthZプラグインを使っていなければ影響を受けない」。

影響を受けるのはAuthZプラグインを導入しており、かつそのプラグインがリクエストボディの内容に基づいてアクセス制御判断を行っている構成に限られる。素のDocker環境、あるいはAuthZプラグインを使わずにTLS/mTLSだけで守っている場合は対象外だ。

バージョン対応表

Docker Engineバージョン状態
29.3.1 以上修正済み
29.3.1 未満（全バージョン）影響あり

修正コミットは e89edb19ad7de0407a5d31e3111cb01aa10b5a38（moby/mobyリポジトリ）。

長年のバグ履歴

この系譜の脆弱性の根は深い。

年出来事
2018〜2019年最初のAuthZバイパスが発見・修正（v18.09.1）
2019年〜v19.03以降で修正が引き継がれずリグレッション
2024年7月CVE-2024-41110として再発見、v27.1.1等でパッチ
2026年3月CVE-2026-34040として上限側のバイパスが発見、v29.3.1でパッチ

eSecurity Planetの記事によれば、この脆弱性クラスはDocker Engine 1.10から数えると約10年にわたって存在し続けている。「完全に直したつもり」のバグが実は半分しか直っていなかった、というパターンだ。

対策

AuthZプラグインを使っている環境は Docker Engine を29.3.1以上に上げる。それが最優先。

即時アップグレードが難しい場合の暫定措置として、公式アドバイザリは以下を挙げている。

  • リクエストボディの内容に依存する判断をAuthZプラグインに委ねない
  • Dockerデーモン APIへのアクセスを信頼できるクライアントのみに絞る（最小権限の原則）
  • rootlessモードでDockerを動かす（ホストへの影響範囲を縮小できる）

アップグレード後は認可ポリシーが期待通りに動いているかを実際のAPIリクエストで確認しておくと確実。パッチバージョンへの移行でAuthZプラグインの挙動が変わるケースは少ないが、ポリシーファイルの互換性は一度検証しておいたほうがいい。

そもそもDockerである必要があるか

今回の脆弱性はDocker Engine固有のAuthZプラグイン機構に起因している。コンテナランタイムとしてDockerを選ぶ必然性がないワークロードなら、アーキテクチャレベルでこの脆弱性クラスを回避できる代替手段がある。

ランタイム特徴AuthZ系リスク
Podmanデーモンレス、rootlessがデフォルト、Docker CLI互換中央デーモンがないためAuthZバイパスの攻撃面自体が存在しない
nerdctl + containerdcontainerdを直接操作するDocker互換CLIAuthZプラグイン機構を持たない。アクセス制御はcontainerdのnamespaceやcgroup単位
Kata Containers軽量VMでコンテナを隔離VM境界による強い分離。ランタイム層のAPI認可とは別レイヤーで防御
gVisor (runsc)アプリケーションカーネルがシステムコールを仲介ホストカーネルへの直接アクセスを遮断。特権コンテナの影響範囲を大幅に縮小

特にPodmanはDocker CLIとほぼ互換で、docker コマンドを podman に置き換えるだけで動くケースが多い。Dockerデーモンという常駐プロセスがそもそも存在しないため、デーモンソケット経由のAPI攻撃という脅威モデル自体が消える。Red Hat系ディストリビューション（RHEL、Fedora）ではDockerに代わるデフォルトのコンテナツールとして採用されている。

ただし、Docker Composeのエコシステムやビルドキャッシュの挙動など、完全互換ではない部分もある。CI/CDパイプラインでDocker-in-Docker構成を使っている場合や、Docker Swarmに依存している場合は移行コストが大きい。

選択の基準は単純で、AuthZプラグインによる細粒度アクセス制御が必要ならDocker Engineをアップデートして使い続ける。それが不要で、rootless実行とデーモンレスアーキテクチャのほうがセキュリティ要件に合うなら、Podmanへの移行は検討に値する。