Red Hat Quayにトークンの署名鍵を足される脆弱性　修正前は「/keys」を塞ぐ

米Red Hatは11月11日（日本時間）、自社のコンテナレジストリ「Red Hat Quay」の脆弱性の情報を公表した。認証なしで、レジストリのトークンに署名する鍵を外から足され、非公開のイメージを読み書きされたり、タグを差し替えられたりし得る。修正版はまだ出ていない。プロキシかロードバランサーで「/keys」への経路を社内の部品だけに絞り、監査ログで見覚えの無い鍵を探す必要がある。

3系と5系の両方が当たる

更新：2026-11-12 06:00（日本時間） SAGUSの環境での確認の方法を具体的に書き、NVDの掲載時刻を外し、CISAの日本語の名前をIPAの表記に合わせた

Red Hatの情報によると、対象と深刻度は次のとおりだ。

• 対象: Red Hat Quay 3（コンテナのイメージquay-rhel8とquay-rhel9）、Red Hat Quay 5（quay-rhel9）。どれも「Affected」で、修正版は示されていない
• CVE番号: CVE-2026-123710
• 深刻度: CVSS 3.1で9.8（Red Hatの評価）。Red Hatの区分は「Critical」。認証も利用者の操作も要らない
• 弱点の種類: CWE-1287（指定された種類の入力の検証の不備）

Red Hatの説明では、鍵を入れ替える処理が、送られてきたトークンの種類を確かめていなかった。誰でも受け取れる匿名のトークンで鍵を足せてしまい、足された鍵は期限なしで信用される。その鍵で署名したトークンは全てのリポジトリで通る。Red Hatは、信頼できない利用者が「/keys」に届く環境が当たるとしている。Red Hatの評価の内訳は、ネットワーク越しに、難しい条件なしで、認証も利用者の操作もなしに狙えることを示す。

NVDの記録にも載ったが、NVDは独自の評価をまだ付けていない。見つけたのはRed HatのDave O'Connor氏だ。Red Hatのバグ管理の記録は11月6日に作られ、優先度は最も高い「urgent」になっている。11月12日の時点で、修正が入った版の欄は空のままだ。

匿名アクセスと経路を確かめる

まず、Red Hat Quayを動かしているか、どの系かを確かめる。動いているコンテナのイメージ名に、quay-rhel8かquay-rhel9が入っているかを見る。サーバーのコンテナで動かしている場合も、OpenShiftのOperatorで動かしている場合も、Podやコンテナのイメージ名で分かる。

次に、Quayの設定ファイル「config.yaml」の「FEATURE_ANONYMOUS_ACCESS」を見る。Red Hatのバグ管理の記録によると、匿名のトークンが出るのはこの設定が有効な時だ。有効なら、認証なしの相手に狙われる。オープンソース版の設定の説明では、この設定は公開リポジトリをログインなしで見て取り込めるようにするもので、デフォルトで有効になる。設定ファイルに書いていなければ有効と見たい。

最後に、プロキシかロードバランサーの設定で、「/keys」で始まる経路が社外から届くかを見る。Red Hatの情報は、届く環境を対象としている。

修正版を待つ間は経路を絞る

Red Hatは回避策として、プロキシかロードバランサーで「/keys」への経路を絞り、信頼できる社内の部品だけが届くようにするよう勧めている。

既に入られていないかも見たい。Red Hatは、監査ログで「service_key_rotate」と「service_key_delete」の記録のうち、期限（expiration_date）が空のものを探し、見覚えの無い承認済みの鍵を消すよう求めている。ただし、修正版を入れるまでは、消しても同じ手口で鍵を足し直されるという。経路を絞ってから消す順になる。鍵を消した後も、同じ記録が再び出ていないかを続けて見る必要がある。

バグ管理の記録によると、問題の処理は公開された最初のコードからあり、開発中の版でも確かめられた。上流のオープンソース版「Project Quay」も、最新のリリースは10月21日（日本時間）のv3.18.2で、修正は入っていない。修正版が出たら、早く上げる必要がある。

悪用の報告はまだ無い

CVE-2026-123710は、11月12日の時点で、米サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の悪用を確認した脆弱性の一覧（KEV）に載っていない。Red Hatの情報にも、悪用の報告は無い。ただし、CVSSの条件のとおり、「/keys」に届きさえすれば認証も利用者の操作も要らない。タグを差し替えられると、同じ名前のイメージを取り込む本番の環境やCIに、別の中身が流れ込む。悪用の報告が無いことは、待ってよい理由にならない。

SAGUSでは当たらなかった

SAGUSは11月12日、開発に使う端末の作業場所にある設定ファイル（YAML、Dockerfile、JSON、TOML）を、「grep -rIl」で「quay.io」「projectquay」「quay-rhel」「FEATURE_ANONYMOUS_ACCESS」の語で検索した。外部のライブラリの置き場（node_modules）を除くと、当たったファイルは0件だった。本番の2つのサイトでも、「curl」で「/keys」と、Quayのレジストリの入口に当たる「/v2/」「/api/v1/discovery」を開き、どのURLも404（存在しない）を返すことを確かめた。SAGUSは自前のコンテナレジストリを動かしておらず、今回の脆弱性には当たらなかった。

編集部の見方

修正版が無い以上、待つ理由は無い。編集部は、Red Hat Quayを社外から届く形で動かす組織は、今日中に「/keys」への経路を絞り、監査ログで期限の無い鍵を探すべきだと考える。鍵を足されると、非公開のイメージが読まれるだけでなく、タグを差し替えられ、本番に別のイメージが流れ込み得る。経路を絞った後も、修正版が出るまでは監査ログの確認を続けたい。