Docker HubのPAT移管問題、秘密は同じまま認証主体が交代していた

組織の自動処理は、誰としてイメージを公開するか

ある開発チームが、Docker Hubの組織リポジトリ（イメージをまとめて保管する場所）へ成果物を自動で公開するとします。これは本稿の架空の運用例です。CI/CDは、変更のテストや公開を自動化する仕組みです。Docker Hubは、アプリケーションと実行に必要なファイルをまとめたコンテナイメージを保管・配布します。

本稿では、認証用の文字列が秘密かどうかに加え、誰として認証され、どの操作を許されるかを確認します。個人アクセス用トークン（PAT）は本人のアカウントに結び付き、組織アクセス用トークン（OAT）は組織に属します [1]。本稿では、組織の処理を個人の権限に依存させるか、組織の資格情報へ分けるかを検討します。

2026年10月12日のDocker公式発表は、CVE-2026-105445を説明しています。CVEは、ソフトウェアなどのセキュリティ上の弱点（脆弱性）に付ける共通識別番号です。個人アカウントを組織へ変換する際、PATの秘密文字列を変えずに所有者記録を別の利用者へ付け替える不具合でした [2]。Dockerは9月30日に、新たな変換でPATを移管する処理を止めています [3]。

秘密は同じでも、結び付く主体が変わっていた

アカウント変換は、個人アカウントを組織へ変える機能です。Docker IDはDockerアカウントの識別名です。アカウント変換機能は、リポジトリの名前空間（所有者や組織を示す部分）と名前を保ち、既存のイメージ取得先を変えずに個人アカウントを組織化できます [4]。アカウント変換機能では、別の既存アカウントを新しい組織の所有者に指定します。

当時は、変換元のPATの所有者記録も新所有者へ移されました。変換処理は秘密文字列を更新・停止せず、指定された所有者にも同意を求めませんでした。変換元アカウントが保持していた同じPATを使うと、レジストリ（イメージの取得・公開などを扱うサービス）は利用者を新所有者として認証しました [2]。レジストリは、イメージの取得・公開などを扱うサービスです。

問題になったのは、自分が管理する個人アカウントを組織へ変換し、別の既存Docker IDを新所有者に指定できる経路です。以下は、秘密・主体・権限の関係を示す概念図です。

可能だった操作は、PATが許可する範囲と、新所有者がアクセスできるリポジトリに制限されます [5]。取得のPull、公開のPush、削除のいずれが可能かは権限設定によって異なります。Pushが許されれば、正規のリポジトリ名で不正なイメージを公開し得るため、Dockerはソフトウェア供給経路（開発から利用者への配布までの流れ）のリスクと評価しました [6]。

Dockerは、この不具合を利用しても攻撃者はWeb画面へ入れないと説明しています。攻撃者は、パスワードやメールアドレス、二要素認証（二つの要素で本人確認する仕組み）の設定を変えられず、アカウント全体も乗っ取れません [7]。利用者は、イメージ操作の潜在的影響と、アカウント管理画面へのアクセスを区別します。

新しい移管の停止と、既存PATへの対応を分ける

Dockerは、影響期間をUTC（協定世界時）で2024年8月26日20時33分から2026年9月30日19時10分ごろまでと公表しています [8]。UTCは協定世界時です。報告、修正、通知、公表は、それぞれ異なる時点で行われました。

時点	Dockerが説明した対応
9月30日	報告を受け、4時間未満でサービスを修正。変換時の新たなPAT移管を停止 [3]
10月2日	影響対象の利用者と関連組織の所有者へ通知 [9]
10月8日	特定した移管PATを無効化。期限前に保持を希望した所有者のトークンは除外 [10]
10月12日	Dockerが経緯と調査結果を公表

対応日付は公式発表の米東部時間のタイムラインに沿っています。公式発表は対応時刻を米東部時間で示しています。本稿では、細かい時刻を日本時間へ換算していません。期間のUTC表記と区別して読んでください。

通知対象は、影響期間の変換でPATを受け取ったアカウントと関連組織の所有者です。Dockerは通知メールに、対象PATの説明文と作成日を記載しました [9]。Dockerは、通知を受け取っていなければ本人と管理組織のメンバーは本件に露出しておらず、対応不要と案内しています [11]。

現行の変換手順では、変換元PATは使えなくなり、新所有者が組織用OATを作成します [12]。新規移管を止めるサービス側の修正と、以前に移管されたPATへの対応を分けると、9月30日の修正と10月8日の無効化の役割が分かります。

10月12日の同じ発表は、指定先への通知と同意取得、所有者変更を誰がいつ行ったかの記録、同様のトークン所有者変更処理の見直しを追加施策に挙げています。Dockerは、これらを進める施策として説明しています。

約304,000回のPushは、被害人数ではない

Dockerは、2024年8月26日以降の変換を調査しました。Dockerは、レジストリ認証ログ（レジストリでの認証記録）、Hub利用データ、ID・アクセス管理（本人確認と権限管理）のトークン記録を照合しました。Dockerが報告した結果は「悪用の証拠を見つけなかった」です [13]。

調べた約304,000回は、移管PATによるPush操作の件数です [14]。人数、組織数、被害件数とは単位が異なります。Dockerは対象利用者を「限られた数」と表現し、具体的な人数を公表していません [15]。

Dockerは、高リスクと判断した公開イメージを実行せずに調べました。Dockerはこの静的解析（実行せずに内容を調べる方法）で、マルウェア（悪意あるソフトウェア）などを確認できなかったと報告しています。対象は、変換後のPushで両アカウントを同じ人物が管理していたと確認できなかった公開イメージです [16]。調査対象は、条件に該当する公開イメージに限られます。

ログが記録するのはトークンの利用です。存在していても使われていない移管PATは、レジストリログに痕跡を残しません [17]。そのためDockerは、利用の検出だけで対象を決めず、期間内に移管されたPATを潜在的対象として扱いました。10月12日の公式アドバイザリには、ログの保管期間や欠落の有無まで記載されていません。「悪用の証拠なし」を、悪用や被害がゼロだった保証に読み替えないことが大切です。

個人PATと組織OATを、用途と条件で選ぶ

以下は2026年10月14日に確認した公式文書の比較です。事件当時の移管仕様と、現行のトークン仕様を分けています。

見る点	PAT	OAT
主体と用途	本人のアカウントとして使う。個人向け文書はPersonal／Pro向け [18]	組織として自動処理を認証する [1]
リポジトリの絞り込み	1つの権限設定が本人のアクセス可能な全リポジトリへ適用。単一リポジトリには絞れない [19]	最大50リポジトリを個別指定、または組織全リポジトリを指定 [20]
利用・管理の条件	本人のアカウント設定から管理する [21]	Team／Business契約と、組織・会社の所有者等の管理権限が必要 [22]
Desktop・Image Access Management（イメージへのアクセス管理機能）	PATを使う [1]	どちらも非対応 [1]

OATの管理権限には、組織所有者、会社に属する組織の会社所有者、専用管理権限を含むカスタムロール（必要な権限を組み合わせて作る役割）が挙げられています。カスタムロール自体はBusinessの機能です。OATの保有上限はTeamが10個、Businessが100個で、期限切れ・無効化済みも削除まで数えられます [22]。

操作を許可する範囲をスコープと呼びます。OATのImage PushはImage Pullを含み、Image DeleteはImage Pushを含みます [20]。本稿の例では、CIは対象リポジトリへのImage Push、配信環境はImage Pullへ分ける案を考えます。Image Deleteは、削除が必要な処理に限って付与します。

組織所有でも、全リポジトリや広い操作範囲を選べば強い権限になります。利用者は対象と操作を必要な分へ絞ります。既存のAPI（ソフトウェア同士が機能やデータをやり取りする仕組み）連携を使う組織は、公式リファレンスでOATの対応経路も確認できます。

本件対応と、日常のトークン管理を分ける

利用者は、本件への対応要否と日常的なトークン管理を分けて考えます。利用者は通知の有無にかかわらず、日常管理を続けます。PAT一覧では説明、権限、状態、生成元、作成日、最終利用時刻、有効期限を確認できます [21]。利用目的と照合し、不要と確認したトークンを停止・削除することが本稿の運用提案です。

PATとOATは作成時に期限を設定でき、既定は無期限です。作成後に期限を変えることはできません [23]。新しい期限へ変えたい場合は、新しいトークンと利用先の設定を用意する必要があります。無効化は再有効化できる停止、削除は恒久的な操作です。期限切れや取り消し済みのPATは削除だけが可能です [24]。

Docker Desktopが自動生成するPATの保持上限は5個です [18]。利用者が定期更新を行う場合は、新しい資格情報の準備、利用先の切替、確認、旧資格情報の停止を別の段階として計画します。本稿は、Dockerの公開情報を基に運用上の考え方を整理しています。

別サービスの形式変更に伴う確認例は、関連記事GitHub Appのインストールトークン移行と確認点で扱っています。今回の要点は、秘密の保持、認証主体の結び付け、許可操作、停止時点を一緒に見て、サービス側の対応と利用者が選ぶ運用を分けることです。