CVE-2026-123710 Red Hat Quay｜署名鍵乗っ取りと影響確認

はじめに

Red Hat は 2026年11月11日、Red Hat Quay の Critical 脆弱性 CVE-2026-123710（CVSS v3.1 9.8）を公開しました。匿名のレジストリトークンが鍵ローテーション用の認証情報として誤って受け入れられるため、攻撃者が Quay の信頼する署名鍵を登録し、任意のリポジトリに読み書きできるトークンを偽造できます。

影響はレジストリ内にとどまりません。プライベートイメージを取得されると、イメージに含まれる認証情報や設定が流出する可能性があります。また、イメージやタグが書き換えられた場合は、そのイメージを取得する CI/CD や Kubernetes のデプロイ先へ影響が及ぶ可能性があります。

本記事でいう署名鍵は、Quay がレジストリへの push / pull を認可するトークン（JWT）の署名鍵です。Cosign などのイメージ署名に使う秘密鍵が漏洩する脆弱性ではない点に注意してください。

結論として、対応の軸は修正版への更新です。更新までの間は /keys へのアクセスを信頼できる内部コンポーネントに限定し、サービス鍵と監査ログを確認してください。不審な鍵は削除しても再登録され得るため、削除だけで対応を終えず修正版を適用し、侵害が疑われる場合はイメージの改ざんとデプロイ先への影響まで確認する必要があります。

CVE-2026-123710 の概要と Red Hat Quay 脆弱性の影響範囲

Red Hat の CVE ページと報道で確認できた概要は次のとおりです。

参考: Red Hat Customer Portal（CVE-2026-123710）
“An unauthenticated client can obtain an anonymous registry token with an audience it controls”
（非認証のクライアントが、自ら制御する audience を持つ匿名レジストリトークンを取得できる）
https://access.redhat.com/security/cve/cve-2026-123710

影響を受ける構成（OpenShift Quay と mirror registry を含む）

Red Hat は、/keys エンドポイントに非信頼クライアントが到達できる構成を影響対象としています。The Hacker News の報道によると、Red Hat のガイダンスはスタンドアロン構成、OpenShift 上で Quay Operator が管理する構成、mirror registry for Red Hat OpenShift を影響対象として挙げています。インターネットに公開しているかどうかではなく、社内ネットワークを含めて攻撃者が Quay に到達できるかで判断します。

CVE の説明は非認証での悪用を前提としています。同報道によると、匿名アクセスが有効（既定値）であればアカウントは不要で、無効にしていても有効な Quay アカウントがあれば悪用でき、Red Hat も匿名アクセスの無効化では防げないと案内しています。この情報は Red Hat のナレッジ記事（solutions/7149923）に基づくとされますが、購読者向けのため本記事では本文を直接確認できていません。匿名アクセスの無効化を回避策とみなさないでください。

なお、同時期に Quay のロボットアカウントのトークンが他テナントから読み取られる CVE-2026-110697（CVSS 9.9）も公開されています。本記事では扱いませんが、Quay を運用している場合はあわせて Red Hat の CVE ページを確認してください。

Quay 修正版と RHSA

2026年11月11日付の RHSA には、少なくとも次の修正版が掲載されています。

Ostorlab の調査は、このほかに 3.9.28、3.16.7、3.18.3 も修正版として挙げています。ただし、本記事の執筆時点では対応する RHSA の CVE 記載を直接確認できていません。これらの系列を利用している場合は、Red Hat の Errata で該当する RHSA を確認してください。

Red Hat は Red Hat Quay 3 と Red Hat Quay 5 を影響対象としていますが、Quay 5 の修正ビルドは確認できていません。また、The Hacker News は確認時点の CVE ページで全パッケージが修正なしと表示されていたと報じており、CVE ページの影響製品表と RHSA は同期していない可能性があります。修正版の判断は、CVE ページの表示ではなく系列ごとの RHSA を基準にしてください。

Quay 署名鍵の乗っ取りが成立する仕組み

Quay は、スキャン要求、ログイン、ストレージアクセスなど、各コンポーネント間のリクエストの署名にサービス鍵を使います（Red Hat Quay ドキュメント）。レジストリの push / pull を認可するトークンも、Quay が承認したサービス鍵で署名・検証されます。つまり、承認済みのサービス鍵の一覧は、レジストリ全体の信頼の起点です。

本来分離されるべき 2 種類の権限

レジストリトークン

/v2/auth が発行し、特定のリポジトリへの pull / push を認可するトークンです。匿名アクセスが有効な環境では、アカウントを持たないクライアントも取得できます。

鍵ローテーション用の認証情報

Quay インスタンスなどの正規コンポーネントが、自身のサービス鍵を更新するときに使う資格情報です。レジストリが信頼する鍵そのものを変更できるため、レジストリトークンとは権限の重さがまったく異なります。

Red Hat の説明によると、鍵ローテーション処理は「承認済みサービス鍵で署名され、期待する audience と issuer を持つか」だけを検証し、そのトークンがローテーション用の資格情報かどうかを確認していませんでした。誰でも取得し得るレジストリトークンが、信頼の起点を書き換える操作に使えてしまうことが問題の本質です。

攻撃の流れ（概念）

1. 攻撃者が /v2/auth から匿名レジストリトークンを取得する。audience は攻撃者が指定できる
2. そのトークンを /keys の鍵ローテーション処理へ提示すると、署名・audience・issuer の検証を通過する
3. 攻撃者の鍵が既存鍵の承認を引き継ぎ、有効期限なしの承認済みサービス鍵として登録される
4. 攻撃者は自身の鍵で、任意のリポジトリへの読み書き権限を持つトークンを署名する
5. Quay が偽造トークンを受け入れ、プライベートイメージの取得、push、タグの差し替えが可能になる

The Hacker News は、正規インスタンスが使う鍵を削除されると push / pull が認証エラーになる可能性（可用性への影響）や、登録された不正鍵が再起動やパスワード変更の後も削除されるまで有効なまま残ることも伝えています。同報道によると、上流の修正（quay/quay のコミット 094cfb024f01）は、ローテーション用資格情報の確認の追加、鍵サーバー経由で追加する鍵への有効期限の要求、呼び出し元がトークンの audience を指定できないようにする変更を含みます。

コンテナレジストリの改ざんがデプロイ先へ波及する条件

攻撃が可能であることと、実際に流出・改ざん・デプロイが発生したことは別の問題です。影響は次の 3 段階に分けて判断します。

タグ指定と digest 固定の違い

タグは可変の参照で、同じタグ名を別のイメージへ付け替えられます。一方、digest はマニフェストの内容から計算されるハッシュで、同じ digest が別の内容を指すことはありません。マニフェストやデプロイ定義でイメージを digest で固定していれば、タグを差し替えられてもそのワークロードが取得するイメージは変わりません。

ただし、digest 固定は改ざんの波及を抑えるもので、読み取りによる流出は防げません。また、Dockerfile の FROM などでベースイメージをタグで参照している場合、次回のビルドで改ざんされたベースイメージを取り込む可能性があります。

実行中コンテナと今後デプロイされるコンテナ

タグが差し替えられても、実行中のコンテナが即座に入れ替わるわけではありません。Kubernetes のドキュメントによると、imagePullPolicy を省略した場合、:latest タグまたはタグなしなら Always、それ以外のタグや digest 指定なら IfNotPresent が設定されます。IfNotPresent ではノードにイメージがあれば再取得せず、Always では kubelet がコンテナを起動するたびにレジストリへ問い合わせて digest を解決します。

改ざんがデプロイ先へ波及するのは、改ざん後にイメージの取得が発生し、その取得を検証で止められなかった場合です。逆に、改ざん後に取得が一度も発生していないワークロードには、タグの差し替えは及んでいません。

独立した署名検証による影響の抑制

今回の脆弱性はレジストリのトークン署名鍵に関するものです。Cosign などのイメージ署名鍵を Quay の外で管理し、デプロイ時に署名検証を強制していれば、一般に攻撃者が署名用の秘密鍵を持たない限り、改ざんしたイメージは検証で拒否されます。ただし、検証を警告のみで運用している場合や、検証の対象外としている名前空間がある場合は抑止になりません。

侵害の痕跡がない環境で、全イメージを直ちに再ビルドする必要があるとは限りません。まずサービス鍵と監査ログで侵害の有無を判断し、その結果に応じて調査範囲を決めると、作業量と見落としのバランスを取りやすくなります。

Quay 署名鍵の監査と復旧の考え方

確認すべき監査イベントとサービス鍵

Red Hat は、expiration_date が null の service_key_rotate と service_key_delete のイベントを監査ログで確認し、認識していない承認済みサービス鍵を削除するよう案内しています。確認の観点は次のとおりです。

service_key_rotate

鍵の差し替えです。有効期限が null のもの、正規コンポーネント以外から実行されたもの、作業予定のない時間帯のものを優先して確認します。

service_key_delete

鍵の削除です。正規インスタンスの鍵が意図せず削除されている場合は、認証障害や不正鍵への置き換えの兆候として扱います。

有効期限が null の承認済み鍵

今回の不正鍵の特徴です。手動で登録した鍵がある場合は、作業記録と照合したうえで判断します。

認識していない鍵の作成

Ostorlab の調査は、認識していない鍵の service_key_create も確認対象に挙げています。

承認済みサービス鍵の一覧は、スーパーユーザー権限で Quay API の listServiceKeys（GET /api/v1/superuser/keys）から取得できます。各鍵の名前、サービス、メタデータ、有効期限を確認してください。

curl -X GET \
  -H "Authorization: Bearer <bearer_token>" \
  "https://<quay_server>/api/v1/superuser/keys"

参考: Red Hat Quay API reference（superuser）

監査ログは、スーパーユーザー向けの listAllLogs（GET /api/v1/superuser/logs）でも取得できます。応答の形式やログの保持期間はバージョンと設定によって異なるため、利用中のバージョンの API リファレンスで確認してください。

Ostorlab の調査によると、失敗した攻撃試行は Quay の監査ログに残らず、/keys への 400 / 403 応答だけが残る場合があります。リバースプロキシ、ロードバランサー、Ingress / OpenShift Route のアクセスログでも、/keys へのリクエストの送信元を確認してください。

正規の鍵ローテーションとの区別

Quay はサービス鍵の自動ローテーション機能を持つため（Red Hat Quay 2.9 リリースノート）、service_key_rotate が記録されているだけでは侵害と判断できません。正規のローテーションか否かは、有効期限の有無、実行元の IP アドレスが Quay インスタンスなど既知のコンポーネントか、鍵の数と稼働中の Quay インスタンスの数が整合しているか、といった観点を組み合わせて判断します。これらは公式の判定基準ではなく、調査の目安です。

鍵の削除と修正適用の関係

不正鍵の削除は、修正版を適用するまで恒久的な対策になりません。脆弱なビルドのままでは、同じ手順で新しい鍵を再登録できるためです。修正前に削除する場合は、先に /keys へのアクセスを制限してください。削除には deleteServiceKey（DELETE /api/v1/superuser/keys/{kid}）を使用できます。

修正版の適用によって、既に登録された不正鍵が自動的に無効化されるかどうかは、確認できた公式情報に記載がありません。更新後も鍵の一覧を確認し、認識していない承認済み鍵が残っていないことを確かめてください。

また、パスワードの変更、ロボットアカウントのトークン再発行、CI/CD の認証情報のローテーションでは、Quay が信頼する署名鍵は失効しません。不正鍵が残っていれば、偽造トークンは引き続き有効です。反対に、不正鍵を削除しても、流出したイメージに含まれていた秘密情報は失効しません。署名鍵の失効と認証情報のローテーションは、別の対策として実施してください。

影響確認から更新までの対応手順（OpenShift Quay を含む）

予防的な更新と侵害時の復旧の違い

調査結果によって、必要な対応の範囲は大きく変わります。

イメージの取得のみが疑われる場合でも、イメージに API キーやパスワードなどの秘密情報を含めていたときは、その秘密情報のローテーションを検討してください。

まとめ

CVE-2026-123710 は、誰でも取得し得るレジストリトークンで Red Hat Quay の信頼する署名鍵を書き換えられる脆弱性です。修正版の適用が対策の軸であり、不正鍵の削除だけでは対応は終わりません。侵害が疑われる場合は、レジストリ内だけでなくデプロイ先への影響まで確認してください。

• 匿名トークンで不正な署名鍵を登録され、全リポジトリの読み書きを許す Critical 脆弱性
• 影響条件は非信頼クライアントから /keys への到達性で、匿名アクセスの無効化は回避策にならない
• 修正版は CVE ページの表示ではなく系列別の RHSA で確認
• 不正鍵の削除は /keys の制限と修正版の適用を前提に実施
• パスワードや CI/CD 認証情報の変更では、不正な署名鍵は失効しない
• タグ差し替えの波及は再取得の有無で決まり、digest 固定と署名検証が抑止策
• 侵害が疑われる場合はタグと digest の履歴、デプロイ履歴、イメージ内の秘密情報まで調査

以上、最後までお読みいただきありがとうございました。