Docker Hub：組織への切り替え時のトークン移管を阻止、所有者の同意・変更履歴を強化

1. 所有者の変更が権限の不正利用につながった経緯

Docker Hubは、リポジトリを別のアカウントに移す機能の代わりに、個人アカウントを組織に切り替える機能を提供している。リポジトリのアドレスを維持し、既存のイメージ取得経路を壊さずに、既存のアカウントを1つ組織の所有者に指定する仕組みだ。

問題は、切り替えたアカウントの個人アクセストークンも新しい所有者に再割り当てされていた点だ。トークンは、パスワードの代わりに自動化で使う認証手段である。所有者の記録だけが変わり、シークレット値は更新も破棄もされず、新しい所有者への同意確認や通知もなかった。

攻撃者は、自分のアカウントでトークンを作成した後、そのアカウントを組織に切り替える際に被害者を所有者に指定できた。すると、攻撃者が知っているシークレット値で被害者として認証できた。他人の持つ入館証の名義だけを被害者に変更したようなものだ。

Dockerは、この問題をCVE-2026-105445として公開した。トークンの権限範囲内で、被害者や被害者がアクセスできる組織のリポジトリのイメージを取得・アップロード・削除できるため、正規の名前でイメージを配布するサプライチェーン上のリスクと評価した。Web画面へのアクセスや、パスワード・メールアドレス・2段階認証の設定変更、アカウントの乗っ取りは不可能だったと説明した。

2. 修正と影響通知の範囲

露出期間は2024年8月26日20:33 UTCから2026年9月30日約19:10 UTCまでだ。Dockerは報告を受けてから4時間未満で修正版を本番環境に展開し、アカウント切り替え時のトークン移管を廃止した。この経路での権限の不正利用を防いだ一方、新しい所有者はトークンを作り直す必要がある。

Dockerは2026年10月2日午後5時30分に、影響を受ける可能性のあるユーザーと関連組織の所有者にメールを送った。続いて10月8日午後3時45分に移管されたトークンを無効化したが、期限前に所有者が維持を求めたトークンは除外した。両時刻は告知に記載された米国東部時間である。

通知には、対象トークンの説明と作成日が含まれていた。Dockerによると、このメールを受け取っていなければ、本人と管理する組織のメンバーはこの脆弱性にさらされておらず、別途対応する必要はない。

3. 悪用調査の結果と残る死角

Dockerは、問題が導入された日以降のアカウント切り替えをすべて調査した。認証ログ、サービス利用データ、トークンの記録を照合し、複数のIDとして使われたトークンを探したほか、移管されたトークンによるイメージのアップロード約30万4,000件をすべて調べた。

悪用の証拠は見つからなかった。イメージのアップロード先は、切り替えた組織か新しい所有者のリポジトリだけで、無関係なユーザーや組織に向けた記録はなかった。切り替えの大半は、同じ人物やチームが両方のアカウントを所有する正規の利用だった。

両方のアカウントを同じ人物が管理していたと確認できなかった切り替えについては、その後アップロードされた高リスクの公開イメージを実行せず、静的に分析した。マルウェアや暗号資産のマイニング、指令・制御通信などの痕跡はなく、Docker自体のインフラやサービスが影響を受けた証拠もなかったと明らかにした。

ただし、ログに記録されるのはトークンの使用であり、その存在自体ではないため、移管後に使われなかったトークンは痕跡が残らない。Dockerは検知の有無で対象を分けず、露出期間中の切り替えで移管されたすべてのトークンを、影響の可能性がある対象とした。

4. ユーザーの確認事項と今後の変更

一般的なセキュリティ点検として、アカウント設定の個人アクセストークン画面で、心当たりのないトークンや使わなくなったトークンを破棄するよう推奨した。組織の自動化には、個人トークンよりも組織アクセストークンを使うよう勧めた。

Dockerは今後の対応として、組織の所有者指定前の同意と指定後の通知、トークンの所有権変更に関する監査可能な履歴の記録、ほかの認証情報の所有権変更フローの点検を挙げた。使用の痕跡に依存していた調査を、所有権の変更自体を記録する方向で補う措置だ。

今回の対応の要点は、トークンの移管を阻止し、組織の所有者指定には同意を、トークンの所有権変更には追跡できる記録を備えることにある。