Docker Hubに重大な脆弱性、他人の権限でコンテナイメージを改ざん可能に―CVE-2026-105445

セキュリティニュース

投稿日時: 更新日時:

Docker Hubに重大な脆弱性、他人の権限でコンテナイメージを改ざん可能に―CVE-2026-105445

Dockerは2026年10月12日、コンテナイメージの共有・配布基盤「Docker Hub」で、攻撃者が別の利用者になりすましてリポジトリを操作できる脆弱性「CVE-2026-105445」を修正したと公表しました。影響する操作は、個人アカウントを組織アカウントへ変換する際のアクセストークンの引き継ぎです。

この問題を悪用すると、攻撃者が事前に保有していたトークンが被害者の権限で認証され、許可範囲に応じてコンテナイメージの取得、公開、削除が可能になる恐れがありました。正規の開発元を装って改ざん済みイメージを配布するソフトウェアサプライチェーン上のリスクがあるとして、Dockerは深刻度を「Critical」と評価しています。

ただし、Dockerは対象トークンを使った約30万4,000件のイメージ公開操作などを調査した結果、実際にこの脆弱性が悪用された証拠は確認していません。2026年9月30日にサーバー側の修正を適用し、影響した可能性のある利用者に通知しています。

Docker Hubの脆弱性「CVE-2026-105445」のサマリー

  • 対象サービス:Docker Hub(コンテナイメージのレジストリサービス)
  • CVE番号:CVE-2026-105445
  • 深刻度:CVSS v4.0で9.4(Critical、Dockerが登録した評価)
  • 脆弱性の分類:CWE-266(不適切な権限の割り当て)
  • 原因:個人アカウントを組織へ変換する際、PAT(個人用アクセストークン)の所有者が変更されても秘密値が失効・更新されず、指名された所有者の承諾も不要だったこと
  • 想定される影響:被害者の権限に基づくリポジトリ内イメージの取得・公開・削除。公開イメージの改ざんやソフトウェア供給網への影響につながる可能性
  • 影響していた期間:2024年8月26日から2026年9月30日の修正まで
  • 修正:Dockerが2026年9月30日にDocker Hubの本番環境へ適用
  • 通知:対象利用者・組織所有者へ10月2日にメール通知
  • トークンへの対応:対象となった移管済みPATを、所有者が明示的に維持を希望したものを除き10月8日に無効化
  • 悪用状況:Dockerの調査では実際の攻撃への悪用やイメージ改ざんを示す証拠なし
項目 内容
製品・サービス Docker Hub
脆弱性 CVE-2026-105445
深刻度 CVSS v4.0:9.4/Critical
問題の機能 個人アカウントから組織アカウントへの変換
影響を受ける認証情報 移管された個人用アクセストークン(PAT)
修正日 2026年9月30日
悪用確認 Dockerは確認していない
利用者への対応 対象者への個別通知、関連PATの原則無効化

攻撃者が保有するPATが、別ユーザーの権限で利用できる問題

Docker Hubでは、個人アカウントを組織アカウントに変換すると、既存のイメージ名や参照先を維持したままリポジトリを組織管理へ移すことができます。変換時には、新たな組織の所有者となる既存のDocker Hubユーザーを指定する仕組みです。

Dockerの説明によると、2024年8月26日以降、この操作に伴って変換元アカウントのPATも指定した所有者へ引き継がれる仕様になっていました。その際、トークンの所有者レコードだけが変更され、認証に使う秘密値はそのまま有効でした。また、新たな所有者の承諾や通知も必要ありませんでした。

このため、第三者が自分で作成したPATを保持したまま別ユーザーの権限に結び付けられる状態が生じました。引き継がれたPATは、レジストリに対して新たな所有者として認証されます。取得・公開・削除の操作がどこまで可能かは、トークンの権限と、なりすまされた利用者がアクセスできるリポジトリの範囲によって決まります。

一方で、Dockerはこの問題がDocker HubのWeb管理画面へのログインや、パスワード・メールアドレス・二要素認証設定の変更を可能にするものではないと説明しています。アカウント全体の乗っ取りではなく、コンテナレジストリへの認証・操作権限が不適切に移管される脆弱性です。

正規名義で改ざんイメージを配布されるサプライチェーンリスク

この脆弱性が悪用され、イメージ公開権限を持つ開発者や組織のリポジトリを操作された場合、利用者は正規の発行元の名前で登録された不正なコンテナイメージを取得する恐れがあります。

アプリケーションのビルドやデプロイを自動化するCI/CDでは、外部レジストリからベースイメージや業務用イメージを取得する構成が一般的です。権限を持つ第三者がイメージを置き換えられると、その後のビルド・デプロイに不正なコードが混入する可能性があります。正規のリポジトリ名で配布されることが、確認を難しくする要因です。

ただし、これらは脆弱性が悪用された場合の想定リスクです。Dockerは、実際に不正なイメージが配布された事実を確認したとは発表していません。

Dockerは約30万4,000件のイメージ公開操作を調査、悪用の証拠なし

Dockerは、問題が存在した2024年8月26日以降のアカウント変換を調べ、トークンの所有権、認証ログ、イメージの公開履歴を突き合わせました。

移管されたトークンによる約30万4,000件のイメージ公開操作を確認したところ、公開先はいずれも変換された組織自身のリポジトリ、または新たな所有者自身のリポジトリでした。無関係の利用者や組織に対する公開操作は確認されなかったとしています。

加えて、アカウント変換前後で同じ人物が両方のアカウントを管理していると確認できないなど、相対的にリスクの高い公開イメージについて静的解析を実施しました。マルウェア、暗号資産マイナー、外部への認証情報送信、不正な永続化処理、改ざんの痕跡は見つからなかったということです。

なお、約30万4,000件は「漏えいしたイメージ数」や「被害件数」ではなく、調査対象となった公開操作の数です。Dockerは、使用されなかったトークンの存在だけではログに痕跡が残らないという調査上の限界も説明し、実際の利用履歴に関係なく移管されたPATを影響対象として扱いました。

9月30日に修正、10月2日通知・10月8日に対象トークンを原則無効化

発見者はセキュリティ研究者のPeter Molnar氏とKrisztian Hozak氏です。両氏はDockerの脆弱性報告窓口を通じ、2026年9月30日に問題を報告しました。Dockerは同日に社内環境で再現し、報告から4時間以内に本番システムを修正しました。

修正後は、個人アカウントから組織への変換時にPATを新たな所有者へ移管しない仕組みに変更されています。Dockerは今後、組織所有者として指名された利用者の同意取得、トークン所有者変更の監査記録、類似する認証情報の所有者変更処理の点検を進めると説明しています。

影響した可能性のある利用者には、10月2日に「Docker Hub Vulnerability Identified & Resolved」という件名で通知が送られました。対象PATは、所有者が継続を明示的に希望したものを除いて10月8日に無効化されています。Dockerは通知を受け取っていない利用者について、本件に関する個別対応は不要としています。

今回の問題はDocker Hubのサーバー側で修正されたもので、Docker EngineやDocker Desktopのローカルソフトウェアを更新することで解消する種類の脆弱性ではありません。

情報システム部門・開発チームが確認したい対策

対象者へ通知済みとはいえ、企業ではDocker Hubのアクセストークンを日常的に使うCI/CD運用について、次の点を整理できます。

  1. Docker Hubから影響通知を受けたユーザーや組織がないか確認し、通知に記載されたPATの扱いを確認する。
  2. Docker Hubの「Account settings」→「Personal access tokens」で、身に覚えのないトークン、長期間未使用のトークン、不要な書き込み・削除権限を持つトークンを見直す。
  3. 組織の自動処理には、個人にひも付くPATではなく、リポジトリ単位で権限を制限できるOrganization Access Token(OAT)を検討する。Dockerの案内ではOATはTeam/Businessプラン向け機能。
  4. Docker Hub上のリポジトリについて、想定外のイメージ更新、公開者、タグの付け替え、イメージのdigestの変化がないかを確認する。
  5. 本番デプロイで使用するイメージのdigest固定、イメージ署名・来歴情報の検証などを利用し、レジストリ上の表示名だけに依存しない確認を導入する。

Docker公式文書は、組織向け自動処理にOATを使い、権限を必要なリポジトリ・操作に絞ること、認証情報をソースコードへ記載しないこと、定期的に不要なトークンを無効化することを推奨しています。また、GitHub Actionsで利用できる環境では、長期保存するトークンを減らすためのOIDC連携も選択肢です。

コンテナイメージの構成や来歴を把握する方法としては、SBOMの目的と活用方法を参照できます。ただし、SBOMは構成部品の可視化を目的とするものであり、それだけでイメージ配布元の正当性や改ざんの有無が保証されるわけではありません。署名、来歴、配布権限の管理と組み合わせて運用します。

関連事例:Dockerイメージの認証バイパスも過去に公表

セキュリティ対策Labでは、2026年7月にGitea公式Dockerイメージの認証バイパス脆弱性(CVE-2026-20896)を報じています。Giteaの事案はコンテナ内アプリケーションの認証設定に起因するもので、今回のDocker Hub自体のトークン移管不備とは原因が異なります。

一方で、いずれも開発・配布基盤における権限と信頼の境界に関わる問題です。コンテナの脆弱性管理では、アプリケーションの修正に加え、イメージを作成・公開する権限、レジストリの設定、デプロイ先での検証方法も確認対象になります。

出典