Azure Red Hat OpenShift の認可不備で権限昇格（Microsoft 側で修正済み）

Critical（CVSS 9.9）に分類されるMicrosoft Azure Red Hat OpenShift (ARO)の脆弱性です。Azure Red Hat OpenShift（ARO）に不適切な認可の問題があり、何らかの権限を既に持つ攻撃者がネットワーク経由で権限を昇格できたとされる。公開されている記述は英文一文だけで、どの API 面での認可漏れかは開示されていない。注目すべきは CVSS が評価元で割れている点で、NVD（Primary、nvd@nist.gov）は 9.9 Critical（CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H）、Microsoft（CNA、Secondary）は 9.1 Critical（CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H）としている。差は攻撃に必要な権限の見立てで、NVD は低権限（PR:L）で足りると評価し、Microsoft は高権限（PR:H）が前提と評価している。スコープ変更（S:C）は両者一致である。Microsoft の Temporal は 7.9（E:U/RL:O/RC:C）で、悪用は未確認（exploited=No）。MSRC は customerActionRequired=false とし、FAQ で「Microsoft 側で既に完全に緩和済みであり、このサービスの利用者が取る作業は無い。CVE の目的は透明性の提供である」と述べている。CPE は cpe:2.3:a:microsoft:azure_red_hat_openshift:- のみでバージョン範囲は無い。CISA KEV には未収載で是正期限は無く、ランサムウェア利用の記録も無い。NVD の vulnStatus は Analyzed。

ARO を使っているかどうかの確認自体は簡単で、az aro list でサブスクリプション内のクラスタが列挙でき、oc version や oc get clusterversion でクラスタ側の版も見える。ただし今回は該当していても適用すべき更新が無い。ARO はコントロールプレーンを Microsoft と Red Hat が運用する形態で、認可処理の欠陥はそのサービス側にあり、利用者が触れる部分（ノードのイメージ、アプリのコンテナイメージ、oc クライアント）に修正対象が無いからである。CPE にバージョン範囲が無いのがその裏付けになる。すぐ更新できない場合の緩和策も存在しない。MSRC は Workaround や Mitigation の節を置いておらず、customerActionRequired=false と明言している。完了条件は、脆弱性管理の台帳で本 CVE を対象外（ベンダー側で修正完了、利用者の作業なし）として根拠を添えて閉じることである。スコアが 9.9 と高いため機械的に緊急対応の列に入りやすいので、閉じる根拠を残しておくことが実務上の要点になる。そのうえで、この CVE と切り離して見直しておくと効くのが権限の棚卸しである。両評価元がいずれも「攻撃者は既に何らかの権限を持っている」（PR:L または PR:H）としており、こうした認可系の問題が現実の被害になるかどうかは、クラスタに対して余分な権限を配っているかどうかで決まる。具体的には ARO クラスタ側の cluster-admin を含む高権限 ClusterRoleBinding が誰に付いているか、サービスアカウントに広い権限を与えたままの名前空間が無いか、Azure 側では ARO リソースに対する Contributor 相当のロール割り当てと、クラスタ作成に使うサービスプリンシパルの権限が必要最小限かを確認する。悪用が確認されていない今のうちにここを整理しておくと、次に同種の CVE が出たときの影響見積もりが速くなる。

Microsoft Azure Red Hat OpenShift (ARO) を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-56160）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。