Red Hatは、同社のコンテナレジストリ製品「Red Hat Quay」に存在する、サービスキー乗っ取りの重大な脆弱性「CVE-2026-123710」を公表しました。CVSS v3.1のスコアは9.8（AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H）です。
認証されていないリモートのクライアントが、レジストリのトークン署名を掌握し、すべてのプライベートリポジトリに対する読み取り・書き込み権限を取得できます。問題は2026年11月11日に公開されました。Red Hatは、Dave O’Connor氏が発見したとしています。
この脆弱性はCWE-1287（指定された型の入力に対する不適切な検証）に分類されています。原因は、Quayのサービスキーサーバーにおける「confused deputy（混乱した代理人）」型の認可の不備です。
キーのローテーションは、ベアラーJWTが承認済みのサービスキーでRS256署名されており、想定されるaudience（対象者）とissuer（発行者）を含むことを確認した時点で認可されます。ところが、サーバーはそのトークンが何のために発行されたのかを確認しません。
FEATURE_ANONYMOUS_ACCESSが有効な場合、/v2/authエンドポイントは匿名の呼び出し元に対して、まさにこのようなトークンを発行します。v2auth.pyでは、audienceがクライアント指定のserviceパラメータからそのまま設定され、固定化されていません。
さらに、キーサーバーの_validate_jwtルーチンは、署名とaud・issクレームを検証した後にペイロードを破棄します。そのため、トークンに付与された権限は無視されます。
攻撃者は、自身のJWKを載せたPUTリクエストを/keys/services/quay/keys/<kid>に送信します。service_keys.pyのreplace_service_key関数は、署名者の承認を新しいキーにそのままコピーします。加えて、expirationパラメータが省略された場合は、有効期限のないキーとして保存します。
不正なキーは直ちに信頼されます。このキーで署名されたレジストリJWTは、任意のリポジトリに対する/v2へのアクセスで受け入れられます。registry_jwt_auth.pyのアクセスクレームが、pull、push、*の権限に直接対応づけられているためです。
攻撃者はプライベートイメージの読み取り、悪意あるレイヤーのプッシュ、タグの上書きが可能です。ソフトウェアサプライチェーンに対する直接的なリスクであり、汚染されたイメージによって下流のワークロードが危険にさらされたGoHarborレジストリの侵害と同様の事態を招きかねません。
ローテーションの副作用として正規のインスタンスキーが削除されるほか、攻撃者のキーは代わりのインスタンスキーも削除できます。このため、防御側は自らの信頼の基点を失うおそれがあります。
Red Hatによると、信頼できないクライアントから/keysに到達できる環境が影響を受けます。報告書は、このロジックが最初の公開コミットから存在していたとし、masterのコミット9226d3a5と3.19-unstableイメージで確認したと説明しています。Bugzillaのエントリ（2568072）のステータスは依然としてNEWで、修正バージョンは示されていません。
この攻撃は、pac4j-jwtの認証バイパスに見られたように、不十分なクレーム検証を突いてトークンを偽造する、おなじみの手口に沿っています。ただし今回の弱点は、ログインフローではなくキー管理プレーンにあります。
Red Hatは、プロキシまたはロードバランサーで/keysエンドポイントへのアクセスを制限し、信頼できる内部コンポーネントだけが到達できるようにするよう推奨しています。管理者は、expiration_dateがnullのservice_key_rotateおよびservice_key_deleteイベントが監査ログにないかを確認する必要があります。
身に覚えのない承認済みサービスキーは、すべて削除してください。ただし、修正ビルドを適用するまでは、不正なキーを削除しても効果は長続きしません。匿名のリクエストによって、新たなキーを再び仕込まれる可能性があるためです。
あわせて、リポジトリを監査し、想定外のタグ変更や見覚えのないイメージダイジェストがないかを確認すべきです。侵害されたコンテナイメージの検出に関するガイダンスにあるように、イメージ署名の検証を徹底すれば、ワークロードが本番環境に到達する前にもう一段階のチェックを加えられます。
署名鍵は最も高い信頼境界に位置するため、audience検証、鍵スコープの限定、ローテーションの自動化を示したNISTのIDトークンに関するガイダンスが、このケースにそのまま当てはまります。
ANY.RUNを導入している16,000以上のSOCチームに加わり、脅威調査を効率化して手作業の負担を減らしましょう。チームで試してみる
翻訳元: https://cyberpress.org/critical-red-hat-quay-flaw/
