Docker HubでPATの所有者が移る脆弱性！イメージ配信の信頼を点検

Dockerは2026年10月12日、Docker Hubで個人アカウントを組織へ変換するとき、Personal Access Token（PAT）が新しい所有者へ移っていた問題を公表しました。CVE-2026-105445として管理されています。9月30日に報告を受けて同日修正し、10月2日に対象者へ通知、10月8日に一部の例外を除いて対象PATを無効化したと説明しています。

本稿は10月21日時点で未掲載だった公表内容の整理です。今日新たにDocker Hubが侵害されたという報告ではありません。Dockerは調査で悪用の証拠を確認していないとしています。自社が使うイメージの出所、CIの資格情報、アカウント変換の履歴をどう確認するかを、公式説明と本サイトの提案を区別して掘り下げます。

一次資料：Docker Hub security advisory CVE-2026-105445（Docker）。以下の運用手順と仮想例は本サイトの提案です。

ログイン画面を奪わなくても配信へ影響する

問題は、変換したアカウントのPATについて、秘密の値を更新したり失効させたりせず、所有者の記録を新しい所有者へ付け替えていたことです。元の秘密を持つ側が、そのトークンの許可範囲内で別ユーザーとしてレジストリーへ認証できる可能性がありました。所有者として指定された側の確認や通知もなかったとDockerは説明しています。

Dockerは、許可範囲によってイメージのpull、push、削除が可能になり得たため、サプライチェーンのリスクとしてCriticalと評価しました。一方で、Docker HubのWeb画面へのアクセス、パスワードやメールアドレス、二要素認証設定の変更、アカウント全体の乗っ取りが可能になった問題ではないと明記しています。

Webサイト運営者にとって重要なのは、本番サーバーへ直接侵入されなくても、正規名のイメージが変更されれば次のデプロイに影響し得ることです。これは今回実際に悪意のあるイメージが配信されたという断定ではなく、公開権限の問題を配布経路まで評価するための考え方です。

対象者と全利用者を混同しない

Dockerは、該当する変換を通じてPATを受け取った限られた利用者と組織所有者に通知したと説明しています。公式は対象の通知を受けていない利用者について、この問題への対応は不要としています。すべてのDocker利用者へ、全イメージの廃棄や全トークンの交換を求める内容ではありません。

通知の確認は、届いたメール内のリンクを無条件に押す作業にしないでください。組織で把握するDockerの管理経路と公式公表ページから内容を照合し、当時の所有者、通知先、対象PATの説明や作成日を確認します。退職者や共有メールに通知が届いていた場合には、現担当が見落とす可能性もあります。

影響期間は2024年8月26日から2026年9月30日の修正までです。Dockerはその間の変換とレジストリー認証などを調査し、悪用の証拠が見つからなかったと報告しています。ただし、未使用のトークンは利用ログに現れません。公式が利用実績の有無だけで対象者を決めなかった点は、資格情報の調査でも参考になります。

CIで使っているPATを見つける

本サイトでは、通知対象のPATを、CIのシークレット、手動リリース端末、イメージミラー、デプロイ基盤、バックアップジョブへ対応付けることを勧めます。秘密そのものを台帳へ複製する必要はありません。管理上の識別子、用途、許可範囲、保管元、失効担当を記録します。

トークンが無効化されても、CIが古いキャッシュを使っていると、すぐに失敗が見えない場合があります。逆に認証失敗が続くからといって、個人の強いPATを急いで投入すると、権限の拡大を招きます。必要なリポジトリーと操作を明確にし、組織の運用に適した資格情報へ計画的に切り替えます。

説明用の仮想例として、Webアプリのreleaseジョブがpush用PATを持ち、別の配備ジョブがpullだけ必要な構成を考えます。両方へ同じ書き込み可能PATを置いているなら、今回の対象かどうかとは別に分離する価値があります。pull経路が侵害された場合に、配信するイメージまで変更される範囲を減らせるためです。

交換は依存先の順序を決めて行う

新しい資格情報を発行する前に、使うジョブ、失敗時の担当、停止してよい時間を整理します。変更は検証環境のレジストリー操作から始め、意図したリポジトリーへ必要な操作だけできることを確かめます。読み取り専用ならpushできないことも、許可された検証用領域で確認します。

本番の切り替えでは、保管元を更新するだけでなく、実際のrunnerや配備プロセスが新しい情報を取得しているかを確かめます。手動で一度成功した結果は、スケジュール実行や再作成されたrunnerの動作を保証しません。次回の自動実行も追跡し、旧PATの利用が残らないことを確認します。

旧資格情報を残す移行期間を設ける場合は、終了条件と失効時刻を決めます。公式が既に無効化したトークンを復活させる想定で進めてはいけません。例外として保持を求めたPATがある場合にも、公式通知と自組織の判断を照合し、誰がそのリスクを引き受けたかを記録します。

イメージはタグだけで確認しない

同じタグは後から別のイメージを指せます。調査では、配備時に使ったダイジェスト、pushした主体、ビルドの実行記録、ソースのコミットを対応付けます。今のタグの内容が正常でも、過去の配備が同じ内容だったとは限りません。可能なら実行中のコンテナが参照するイメージ識別子も残します。

署名や来歴情報がある場合は、それが何を保証しているかを確認します。署名が正しくても、署名するCIそのものが不正操作を受ければ、危険な成果物へ正規の署名が付く可能性があります。署名、ビルドの権限、ソースの変更承認、資格情報の管理を合わせて評価してください。

対象期間に不自然なpushが見つかった場合は、そのイメージを本番へ新規配備しないよう保留し、クリーンなソースと管理されたビルド環境から再作成する判断が必要です。疑わしいイメージを調査目的で業務端末に起動すると、新たな実行経路を作ります。静的な情報を先に保全し、必要な解析は隔離環境で行います。

悪用が見つからないという報告の読み方

Dockerの調査結果は、提供元が確認できた記録に基づくものです。全利用者が侵害されたという主張にも、すべての自社環境が無条件に安全という保証にも置き換えません。対象者は通知内容、利用履歴、リリース履歴を照合し、記録のない期間を明示した上で対応を閉じます。

この問題に関する独自調査で異常を見つけても、すぐに本CVEが原因と決めつけないことが大切です。CIの侵害、ソース変更、別のトークン漏えいでも似た現象が起き得ます。時系列をそろえ、どの認証情報でどの操作が行われたかを確認し、影響範囲に応じて提供元へ連絡します。

アカウント変換を保守作業として扱う

配信の履歴から対応範囲を決める例

仮想のチームで、同じイメージを検証、本番、外部向けデモへ配備しているとします。通知対象のPATがpushに使われていた場合、対象期間のpushから、どのダイジェストがどの環境へ届いたかをたどります。現在の本番だけでなく、停止中のデモや後で再開する検証環境も確認の対象です。

履歴がそろわない場合は、何が不明なのかを明確にします。タグの変更履歴がない、CIのログが失効している、実行中コンテナの識別子だけ残るなど、材料によって評価が変わります。記録がないことを改ざんの証拠にも安全の証拠にもせず、必要なら既知のソースから再ビルドした成果物へ置き換える判断をします。

再ビルドではソースのコミットだけでなく、依存関係、ベースイメージ、ビルド用ツールも固定できる範囲で記録します。同じソースから作っても、最新タグの依存先が変われば内容は同じになりません。調査用の再現と通常の最新版への更新は目的が異なるため、どちらを行ったかを作業票に残します。

新しい成果物を配備するときには、読み取り専用の配備資格情報で取得できること、古いPATを設定したジョブが残らないことを確認します。認証失敗を直すために全レジストリーへの書き込み権限を付けると、問題の範囲を広げます。権限を足す前に、リポジトリー名、対象組織、必要な操作が正しいかを確認してください。

組織への変換を今後行う場合には、実施前後の所有者と資格情報の状態を確認するチェックを追加します。旧アカウントが使っていた秘密を自動的に新所有者へ渡す前提を置かず、新しい所有者が管理する資格情報へ切り替えます。保存済みシークレットの名称だけ変えて、中身を使い回す移行にも注意が必要です。

配布基盤で重要なのは、誰がログインできるかだけでなく、誰が正規名の成果物を変更できるかです。今回の公式説明に沿って対象者を限定しつつ、イメージの公開履歴と配備履歴を結べる状態へ改善すると、今後別の資格情報問題が起きた際にも影響範囲を判断しやすくなります。

レジストリーの操作権限を見直す際は、利用者のWebログインにMFAがあることと、CIが持つPATの権限を別々に確認します。対話型の認証が強くても、既存トークンの許可範囲が自動的に小さくなるとは限りません。作成、利用、失効の各記録をそろえ、使われていない強い資格情報も定期的に整理することを勧めます。

今回の教訓は、アカウントや組織の変換を名前の変更だけとして扱わないことです。所有権が変わるときは、資格情報、チーム権限、連携アプリ、Webhooks、請求主体、リリース承認を確認する変更作業にします。機能ごとの引き継ぎと、引き継いではいけない秘密の失効を分けて設計します。

完了の目安は、公式通知の対象判定が済み、対象資格情報の利用先が分かり、CIが意図した権限で動き、イメージの出所を説明できることです。個人アカウントの認証設定だけを点検して終わらず、レジストリーと自動配備の間にある信頼関係を確認してください。