Dockerは、Docker Hubの重大な脆弱性を修正しました。この脆弱性を悪用すると、攻撃者はパーソナルアクセストークン(PAT)を使って別のユーザーとして認証を受け、そのユーザーのレジストリ権限の範囲内でコンテナイメージの取得、プッシュ、削除を行える可能性がありました。
この脆弱性は「CVE-2026-105445」として追跡されています。原因は、アカウントから組織への変換時に、受け取る側の同意も通知もなくトークンが移管されていたことです。Dockerは、悪用された形跡は確認されていないとしています。
この問題は2026年9月30日、セキュリティ研究者のPeter Molnar氏とKrisztian Hozak氏がDockerの脆弱性開示プログラムを通じて報告しました。
Dockerは問題を再現し、報告を受けてから4時間足らずの同日中に修正を展開しました。同社は10月12日に脆弱性を公表しました。
Docker Hubでは、個人アカウントを組織に変換できます。その際はリポジトリ名が維持されるため、既存のイメージ参照はそのまま機能します。変換を開始した人物は、変換時に既存のDocker Hubユーザーを組織の新しいオーナーに指名できました。
2024年8月26日以降、この変換処理ではアカウントのPATも、指名されたオーナーに移管されるようになりました。トークンの所有者情報は書き換えられたものの、シークレット値は無効化もローテーションもされませんでした。しかも受け取る側には、移管の承認を求めることも、移管が行われたことを通知することもありませんでした。
そのため攻撃者は、使い捨てのアカウントを作成してPATを生成し、そのアカウントを組織に変換したうえで、標的をオーナーに指名することが可能でした。
トークンは標的としてレジストリに認証されますが、シークレットは攻撃者の手元に残ります。このトークンは標的のレジストリ権限の範囲で動作するため、そのユーザーが所有するリポジトリや、ユーザーがアクセス権を持つ組織のリポジトリにアクセスできる可能性がありました。
このアクセスはソフトウェアサプライチェーン上のリスクを生みます。攻撃者が、信頼されたユーザーや組織の名義でイメージを公開したり、改ざんしたりできる可能性があったためです。
Dockerによると、この脆弱性ではHubのWebインターフェースにはアクセスできず、被害者のパスワード、メールアドレス、二要素認証の設定も変更できませんでした。つまり、可能だったのはレジストリレベルでのなりすましにとどまり、ユーザーのDockerアカウント全体の乗っ取りには至りません。
影響を受ける可能性があった期間は、2024年8月26日から修正を展開した2026年9月30日までです。Dockerはこの期間中のアカウント変換を調査し、レジストリやトークンの記録と突き合わせました。さらに、移管されたトークンによる約304,000件のプッシュを調べました。
同社は、悪用の形跡はなかったと報告しています。調査したプッシュはいずれも、変換後の組織または新しいオーナーに属するリポジトリへのものであり、無関係のアカウントへのものではありませんでした。また、選定した公開イメージの静的解析でも、マルウェアなどの不審な活動は見つかりませんでした。
一方でDockerは、レジストリのログに記録されるのはトークンの使用であり、すべてのトークンの存在ではないと注意を促しています。影響を受けたトークンが一度も使われていなければ、認証の痕跡が残らない可能性があります。そのため同社は、脆弱な処理で移管されたすべてのPATを、影響を受けた可能性があるものとして扱いました。
Dockerはアカウント変換からトークンの移管機能を削除し、10月8日には、特定した移管済みPATのうち、ユーザーが保持を希望したものを除いて無効化しました。
同社は、影響を受けた可能性のあるユーザーと組織オーナーに対し、10月2日にメールで通知したとしています。あわせて、オーナーの同意取得と通知の仕組みを追加し、トークンの所有者変更を記録するほか、他の認証情報の移管フローも見直しを進めています。
Dockerは、ユーザーに対し、アカウント設定でPATを確認し、見覚えのないものや不要なものを失効させるよう勧めています。組織に属する自動化処理には、個人のPATではなく組織アクセストークンの使用を推奨しています。
脅威調査の効率化と手作業の削減のために、1万6,000以上のSOCチームがANY.RUNを活用しています。チームでの導入を検討する
翻訳元: https://cyberpress.org/critical-docker-hub-flaw/
