CVE-2026-116472はRHOSO 18に影響する？ ingress-nginxとOpenShift標準Ingressの違いを確認

2026年11月6日 08:50

CVE-2026-116472は、Kubernetesコミュニティのingress-nginxに関する脆弱性です。
RHOSO 18を運用していると、「OpenShiftにもIngressがあるけれど、影響するのだろうか？」と気になるかもしれません。

結論から言うと、
「RHOSO 18とOpenShiftの標準Ingress Controllerを使用し、対象のingress-nginxを別途導入していない構成には、この脆弱性は直接該当しません。 」
OpenShift標準のIngress ControllerはHAProxyベースであり、今回の対象であるingress-nginxとは別の実装だからです。

ただし、同じOpenShiftクラスタにingress-nginxを追加している場合や、RHOSO上の仮想マシン内などで別のKubernetesクラスタを運用している場合は、それぞれ確認が必要です。
この記事は2026年11月5日時点の公開情報に基づく構成上の判断であり、Red Hatによる本CVEの製品別評価を確認できたという意味ではありません。

1. CVE-2026-116472の概要

Kubernetesの公表によると、ingress-nginxでIngressを作成できる権限を持つユーザーが、mirror-targetアノテーションを悪用し、コントローラー内部の認証のない設定APIに書き込みを行える可能性があります。

その結果、ingress-nginxを通過する通信が、Ingress設定の変更またはコントローラーの再起動によって設定が再生成されるまで停止するおそれがあります。
同じコントローラーが管理する別のIngressの通信をリダイレクトできる可能性も説明されていますが、そのためには内部状態に関する特権的な情報が必要とされています。

公表されたCVSS v3.1スコアは2.7（Low）です。
対象はingress-nginxを使用しているクラスタであり、KubernetesやOpenShiftを使っているだけで一律に該当するわけではありません。

2. なぜRHOSO 18の標準構成には直接該当しないのか

RHOSO 18のコントロールプレーンはOpenShift上で稼働します。
OpenShiftのIngress Operatorが管理する標準Ingress ControllerはHAProxyベースで、RouteやKubernetesのIngressリソースに従って外部からサービスへの通信を振り分けます。

一方、今回のCVEはコミュニティ版ingress-nginxのmirror-targetアノテーションと、そのコントローラー内部の処理に関するものです。
標準のHAProxyベースのルーターは、このingress-nginxの処理をそのまま使用していません。

構成の違いを整理すると、次のようになります。

今回の対象：Kubernetesコミュニティのingress-nginxをIngress Controllerとして使用する構成
OpenShiftの標準構成：Ingress Operatorが管理するHAProxyベースのIngress Controllerを使用する構成
追加導入した構成：OpenShift上に別途ingress-nginxを導入していれば、そのコンポーネントを個別に評価

「Ingress」というリソース名があることと、「ingress-nginx」という実装を使用していることは同じではありません。
また、一般的なNGINXという名前だけでも対象かどうかは決まりません。

3. 環境で確認する方法

以下は参照のみのコマンドです。対象のOpenShiftクラスタに管理者権限などでログインし、クラスタ全体を参照できる権限で実行してください。
権限不足やAPIエラーが出た場合は、未導入とは判断できません。

① OpenShift標準のIngress Controllerを確認する

oc get ingresscontroller -n openshift-ingress-operator
oc get pods -n openshift-ingress -o wide

通常はIngressControllerのdefaultや、router-defaultで始まるPodが確認できます。
これは標準ルーターの確認であり、同じクラスタに別のIngress Controllerが存在しないことの証明にはなりません。

② ingress-nginxの代表的なラベルでPodを探す

oc get pods -A -l app.kubernetes.io/name=ingress-nginx

このコマンドはKubernetesの公表でも案内されている確認方法です。
該当Podが表示された場合は、名前空間やイメージ、提供元、バージョンを調べ、対象かどうかを確認します。

一方、No resources foundと表示されても、独自ラベル、停止中のワークロード、別クラスタなどは検出できないため、これだけで完全に未導入とは断定できません。

③ IngressClassとワークロードも確認する

oc get ingressclass -o yaml
oc get deployments,daemonsets -A -o wide

IngressClassのspec.controllerが「k8s.io/ingress-nginx」であるものや、ingress-nginxに関連する名前・イメージのワークロードがないか確認します。IngressClassの存在だけでは稼働中とは限らず、逆に名前やラベルが異なる場合もあるため、導入台帳やHelmリリースなどとも照合してください。

疑わしいDeploymentが見つかった場合は、名前空間と名前を実際の値に置き換えて、コンテナーイメージなどを確認します。

oc -n <namespace> get deployment <deployment-name> -o yaml

DaemonSetの場合はdeploymentをdaemonsetに置き換えます。
イメージ名だけでなく、ディストリビューション、バージョン、提供元のセキュリティ情報まで確認することが大切です。

④ RHOSOの外側や仮想マシン内も確認する

上記のocコマンドが確認するのは、接続先のOpenShiftクラスタです。
外部ロードバランサー、別のKubernetesクラスタ、RHOSO上の仮想マシン内のKubernetesなどは別途確認してください。
確認対象の仮想マシンを把握する

OpenStack CLIを使用できる環境で、仮想マシンの一覧を確認します。

openstack server list --all-projects --long

全プロジェクトの一覧表示には適切な権限が必要です。権限がない場合は、プロジェクトごとに次のコマンドを実行します。

openstack server list --long

一覧を構成管理台帳などと照らし合わせ、Kubernetesを運用している仮想マシンがないか確認します。
VMの一覧だけではKubernetesやingress-nginxの導入有無は分かりません。VM名だけで判断せず、利用者やシステム管理者にも確認してください。

別のKubernetesクラスタを確認する

対象クラスタに接続できる環境で、まず現在の接続先を確認します。

kubectl config current-context
kubectl config get-contexts

現在選択されているコンテキストには「*」が表示されます。一覧に表示されるのは、そのkubeconfigに登録されている接続先だけであり、組織内のすべてのクラスタではありません。
接続先が確認対象と一致していることを確認します。

対象クラスタで、ingress-nginxの代表的なラベルを持つPodを検索します。すべての名前空間を参照できる権限が必要です。

kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx

表示例：

NAMESPACE       NAME                                        READY   STATUS
ingress-nginx   ingress-nginx-controller-xxxxxxxxxx-xxxxx   1/1     Running

Podが見つかった場合は、名前空間とPod名を実際の値に置き換えて、コンテナーイメージを確認します。

kubectl -n <namespace> get pod <pod-name> -o jsonpath='{range .spec.containers[*]}{.name}{"	"}{.image}{"
"}{end}'

イメージの提供元、製品、バージョンを調べ、提供元のセキュリティ情報を確認してください。

Podに加えて、IngressClassやワークロードも確認します。

kubectl get ingressclass -o yaml
kubectl get deployments,daemonsets -A -o wide

IngressClassのspec.controllerが「k8s.io/ingress-nginx」であるものや、ingress-nginxに関連する名前・イメージのワークロードを探します。
No resources foundと表示されても、独自ラベルや停止中のPodなどは検出できません。
IngressClassの有無だけでも稼働状況は確定できないため、導入台帳やHelmリリースなどとも照合してください。
権限不足やAPIエラーの場合も未導入とは判断できません。

仮想マシン内のKubernetesを確認する

RHOSO上のVM内でKubernetesを運用している場合も、そのクラスタに接続して上記のkubectlコマンドを実行します。
例えば、対象VMにkubectlと接続設定が用意されている場合は、以下で確認できます。

kubectl config current-context
kubectl get pods -A -l app.kubernetes.io/name=ingress-nginx
kubectl get ingressclass -o yaml
kubectl get deployments,daemonsets -A -o wide

VMにログインしただけでは対象クラスタに接続されるとは限りません。
接続先をクラスタ管理者の把握している情報と照合してください。
また、VMにkubectlがなくてもKubernetesノードではないとは判断できません。
別の管理ホストから確認する場合もあります。

外部ロードバランサーを確認する

外部ロードバランサーは製品や構成によって確認方法が異なります。
まず構成図や機器台帳で製品名、配置場所、転送先を確認します。
Linux上で稼働する場合は、次のコマンドで実行中のプロセスを確認できます。

ps -ef | grep -E '[h]aproxy|[n]ginx|[e]nvoy'

この結果がヒントとなります。
haproxyの表示だけでシステム全体にingress-nginxがないとは言えず、nginxの表示だけでコミュニティ版ingress-nginxに該当するとも言えません。
別ノードやコンテナー内で動作するものは確認できない場合があります。

ロードバランサーがKubernetes上で動作する場合は、そのクラスタでもkubectlで確認します。
アプライアンスやクラウド型の場合は、製品の管理画面や提供元のセキュリティ情報を確認してください。

確認のポイント：各Kubernetesクラスタを個別に調べます。
VM一覧やロードバランサーのプロセス一覧は確認対象を探す手がかりであり、単独でingress-nginxの未使用を証明するものではありません。
RHOSOの標準構成に該当しなくても、これらで対象コンポーネントを使用していれば影響を受ける可能性があります。

4. ingress-nginxが見つかった場合は？

まず、どの製品・ディストリビューションのingress-nginxかを特定し、提供元のアドバイザリーとサポート方針を確認します。
Kubernetesコミュニティは、ingress-nginxのメンテナンスが2026年3月に終了したため、このCVEの修正版は提供しないとしています。
公表では、SUSEが自社フォーク向けに修正版を提供したことも案内されていますが、ほかの製品すべてに適用できる修正版という意味ではありません。

公表されている緩和策には、Admission Controllerでmirror-targetアノテーションを持つIngressを拒否する方法、またはannotations-risk-levelをMediumもしくはLowに設定する方法があります。
後者はほかのアノテーションにも影響する可能性があるため、利用中の設定と提供元の手順を確認し、検証環境で影響を評価してから適用してください。
長期的にはサポートされる代替Ingress／Gateway実装への移行も検討します。

まとめ

CVE-2026-116472の対象はingress-nginxです。RHOSO 18を支えるOpenShiftの標準Ingress ControllerはHAProxyベースなので、標準構成でingress-nginxを追加していなければ、このCVEは直接該当しません。

ただし、追加導入したIngress Controllerや別クラスタまで含めて確認することが重要です。
最終的な製品別の影響や対応は、Red Hatおよび該当コンポーネント提供元の最新情報を確認してください。

Kubernetes：CVE-2026-116472の公表
https://github.com/kubernetes/kubernetes/issues/143852

Kubernetes Security Response Committeeの告知
https://seclists.org/oss-sec/2026/q4/523

Red Hat：OpenShift Container Platform 4.18 Ingress Operator
https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html-single/networking_operators/index

Red Hat Security：CVE情報検索
https://access.redhat.com/security/security-updates/