Docker Engineで、高深刻度の脆弱性CVE-2026-34040が公表されました。特定条件下で認可プラグインをすり抜け、権限の強いコンテナ作成やホスト側ファイルへの到達につながる可能性があるとされています。とくに、リクエスト本文を見てアクセス制御を判断する運用では注意が必要です。修正版はDocker Engine 29.3.1で提供されています。
The Hacker News：Docker CVE-2026-34040 Lets Attackers Bypass Authorization and Gain Host Access
この記事のポイント
影響のあるシステム
- Docker EngineのAuthZ（authorization plugins）を利用している環境
- リクエスト本文を参照してアクセス制御を判断する認可プラグイン運用
- Docker APIへのアクセス権を持つユーザーやプロセスが存在する環境
- 権限制御されたDocker APIを使うCI/CD、開発基盤、マルチテナント型コンテナ環境
- Dockerベースのサンドボックス内で動作するAIコーディングエージェント運用
- ホスト上にAWS認証情報、SSH鍵、Kubernetes設定、各種シークレットを置く運用
推奨される対策
- Docker Engineを29.3.1へ更新する
- 暫定策として、リクエスト本文の検査に依存するAuthZプラグイン運用を見直す
- Docker APIへのアクセスを信頼された主体のみに制限し、最小権限を徹底する
- 可能であればDockerをrootless modeで運用する
- rootless移行が難しい場合でも、権限境界とホスト上の機密配置を再点検する
- 権限付きコンテナ作成や不審なホストマウントの有無を監視する
上記の対策は、元記事の事実に基づき日本の読者向けに整理したものです。
この記事に出てくる専門用語
- CVE-2026-34040：Docker Engineで報告された脆弱性識別子です。記事ではCVSSスコア8.8とされています。
- AuthZ plugin：Docker Engineで認可制御を追加するためのauthorization pluginです。特定のAPI要求を許可または拒否する判断に使われます。
- CVE-2024-41110：2024年7月に公表された同系統コンポーネントの脆弱性です。今回の問題は、その修正が不完全だったことに起因すると説明されています。
- rootless mode：Dockerデーモンとコンテナを非rootユーザーで動かす仕組みです。侵害時の影響範囲を抑える目的で利用されます。
- prompt injection：AIエージェントに対して、意図しない指示を紛れ込ませて不適切な処理を誘導する手口です。
- kubeconfig：Kubernetesクラスタへ接続するための設定情報です。流出すると管理操作に悪用される可能性があります。
問題の本質は、認可プラグインが「見るべき本文」を見られないまま通してしまう点です
今回のCVE-2026-34040は、Docker Engineの認可プラグイン機構に関する脆弱性です。記事では、細工したAPIリクエストを使うことで、Dockerデーモンが認可プラグインへ本文なしで要求を転送してしまう可能性があると説明されています。その結果、本来であれば拒否されるはずの操作が、プラグイン側では判断材料を欠いたまま許可されるおそれがあります。Dockerのメンテナーは、この問題がCVE-2024-41110への修正が不完全だったことに起因すると説明しており、同じ認可まわりの防御線が再び破られた形です。とくに影響を受けやすいのは、リクエスト本文の内容を確認してアクセス制御を行うAuthZプラグイン運用です。本文が正しく渡らないと、表面的には通常の要求に見えてしまい、危険な設定や高権限操作を見逃す可能性があります。見かけ上は「認可機構が有効」でも、実際には判断に必要な情報が欠落していれば、最終防衛線としての役割を果たせなくなる点が重要です。
単一の大きなHTTPリクエストから、権限付きコンテナとホスト到達へ進む可能性があります
Cyera Research Labsの報告として記事が紹介している内容では、この問題は過大なHTTPリクエスト本文の扱いに起因し、1MBを超えるようにパディングした要求を1回送るだけで、認可プラグインを迂回できるシナリオが示されています。想定例では、AuthZプラグインにより制限されているDocker API利用者が、コンテナ作成要求を大きく膨らませることで、その本文がプラグイン到達前に捨てられ、プラグインは拒否理由を認識できないまま通してしまうとされています。記事ではその結果として、権限付きコンテナが作成され、ホストのファイルシステムへアクセス可能になる可能性があると説明されています。さらに、AWS認証情報、SSH鍵、Kubernetes設定など、ホスト上にある各種機密へ到達し得る点が強調されています。これはコンテナ内部の権限問題にとどまらず、クラウドアカウント、Kubernetesクラスタ、本番サーバーへのSSH接続へ連鎖するおそれがあるということです。Docker APIに触れられる主体が限られていても、その境界がAuthZプラグインに依存している場合、想定以上に影響が広がる可能性があります。
AIエージェントを含む開発フローでも、正規作業の延長で悪用されるおそれがあります
今回の記事で見逃せないのは、AIコーディングエージェントとの組み合わせが取り上げられている点です。記事では、Dockerベースのサンドボックス内で動くOpenClawのようなAIエージェントが、細工されたGitHubリポジトリに埋め込まれたプロンプトインジェクションにより、不正コード実行へ誘導されるシナリオが説明されています。その流れの中でCVE-2026-34040が悪用されると、認可をすり抜けて権限付きコンテナを作成し、ホストファイルシステムをマウントできる可能性があります。さらに記事では、エージェント自身が通常のデバッグ作業中に失敗へ遭遇し、たとえばkubeconfigへアクセスできない理由を探る過程で、Docker API仕様を踏まえてこの回避手法を自力で組み立てる可能性にも言及しています。つまり、明示的に悪意あるリポジトリを踏ませなくても、与えられた正規タスクの延長で危険な操作へ到達する懸念があるということです。AIエージェントにDocker APIやホスト資産への橋渡しをさせている環境では、単純なサンドボックス前提だけでは不十分である可能性があります。
今すぐ確認したいのは、パッチ適用だけでなくAuthZ依存とAPI露出の実態です
対策として最優先なのは、修正版であるDocker Engine 29.3.1への更新です。記事でも、このバージョンで問題が修正されたと明記されています。そのうえで暫定策として、リクエスト本文の検査に依存するAuthZプラグインを安全判断の中心に置き続けないこと、Docker APIへのアクセスを信頼された主体のみに絞り込むこと、そして可能ならrootless modeで動かすことが推奨されています。Cyeraの説明では、rootless modeでは権限付きコンテナ内のrootであっても、ホスト側では非特権UIDに対応するため、影響範囲を「ホスト全面侵害」から抑えられる可能性があります。日本企業の実務では、CI/CD、検証環境、開発者向けサンドボックス、AI補助開発基盤などにDocker APIが広く使われているケースがあります。だからこそ、単にバージョンを上げるだけでなく、AuthZプラグインに何を期待しているのか、Docker APIへ誰が到達できるのか、ホスト上にどの機密があるのかまでをまとめて確認することが現実的です。
