JVN（Japan Vulnerability Notes）は、レッドハットのRed Hat Advanced Cluster Management for Kubernetes 2において、パストラバーサルの脆弱性があると公表した。当該脆弱性は、Insights クライアントコンポーネント（insights-client）に起因し、特定の条件下で認証済みリクエストが意図しない API エンドポイントへ到達し得る問題である。影響範囲の確認と、ベンダーが提供する修正の適用が重要となる。
脆弱性の詳細
JVN（Japan Vulnerability Notes）によると、Red Hat Advanced Cluster Management for Kubernetes 2 の insights-client コンポーネントにパストラバーサルの脆弱性が存在する。パストラバーサルは、本来アクセスできないはずのファイルやディレクトリ、または API エンドポイントへ、特殊なパス指定などを悪用して到達される可能性がある問題であり、本件は CWE-22（Improper Limitation of a Pathname to a Restricted Directory）として分類されている。結果として、情報の参照や設定の改変など、製品が提供する機能の範囲を超えた影響につながるおそれがある。
この脆弱性では、管理対象クラスタ（いわゆる「spoke」クラスタ）が制御する ClusterID が、URL エンコードや妥当性検証を十分に行わずに Insights API のリクエストパスに直接使用されることが問題となる。攻撃者によりすでに侵害された spoke クラスタが悪意のある ClusterID を注入した場合、Insights クライアントが発行する認証済みリクエストが、意図しない API パスへリダイレクトされ、機密情報の露出や権限外の API 呼び出しにつながる可能性がある。なお、本件のCVE番号は CVE-2026-71475であり、CVSSv3 のベーススコアは5.0（中程度）と評価されている。
JVN（Japan Vulnerability Notes）は、当該脆弱性が、spoke クラスタへの侵害の有無、外部から到達可能な経路、認証要否などの条件により、悪用リスクや影響が変わりうる点に留意するよう促している。攻撃者がこの種の欠陥を悪用できる状況では、意図しない API パスへのアクセスを起点に、機密情報の露出や運用妨害につながる可能性があるため、公開情報に従って影響評価と対処を行うことが求められる。
JVN（Japan Vulnerability Notes）は、ベンダー情報に基づき、影響を受ける製品・バージョンの特定と、修正済みバージョンへの更新を推奨している。自社環境で Red Hat Advanced Cluster Management for Kubernetes 2 を利用している場合、まずは当該コンポーネント（insights-client）の利用有無、公開範囲、アクセス権限の設計を含めて確認し、優先度を付けて対応を進める必要がある。
影響を受ける製品・バージョン
- Red Hat Advanced Cluster Management for Kubernetes 2（insights-client コンポーネント。影響を受けるバージョンの詳細は JVN（Japan Vulnerability Notes）の当該アドバイザリおよびベンダー情報に記載）
- その他、JVN（Japan Vulnerability Notes）が当該アドバイザリで挙げる関連製品（該当の有無は現時点で不明であり、JVN及びベンダーの情報に基づき要確認）
推奨される対策
- 修正済みバージョンへの更新：JVN（Japan Vulnerability Notes）が参照するベンダー情報に従い、影響を受けるバージョンから修正済みバージョンへアップデートする。Red Hat が提供するセキュリティアドバイザリおよび更新済みコンテナイメージに基づき、insights-client を含む関連コンポーネントを最新状態にする。
- 暫定回避策の適用：すぐに更新できない場合、JVN（Japan Vulnerability Notes）やベンダーが示す回避策や緩和策（特定機能の無効化、設定変更、アクセス制限など）が提供されていれば適用する。詳細な暫定策の有無は現時点で不明であり、公式情報の確認が必要である。
- 外部公開範囲の見直し：管理画面や API など、Red Hat Advanced Cluster Management for Kubernetes 2 に到達できるネットワーク経路を必要最小限にし、不要な公開を停止する。特に spoke クラスタからの通信経路や管理系 API エンドポイントの露出状況を点検する。
- 権限の最小化：該当機能を利用するアカウントやサービスの権限を最小化し、API 参照や設定変更が過剰になっていないか点検する。Insights クライアントが利用する認証情報の権限範囲を見直し、不要な権限を削減する。
- ログの確認：更新前後で、関連コンポーネントのアクセスログや監査ログを確認し、不審なパス指定や異常なリクエストがないか点検する。ClusterID を含むリクエストパスに不自然なディレクトリトラバーサル文字列が含まれていないかを確認する。
日本の中小企業が今すぐ取るべき行動
- 最優先：自社の利用有無とバージョンを特定：クラスタ管理、ポリシー管理、監視などに Red Hat Advanced Cluster Management for Kubernetes 2 を使っているかを洗い出し、稼働バージョンと insights-client コンポーネントの有無を確認する。
- 次に：公開範囲と到達経路を棚卸し：管理系エンドポイントが社外から到達可能になっていないか、VPN や踏み台経由の経路も含めて確認する。spoke クラスタからの通信経路についても、不要なルートや露出がないかを点検する。
- 対応計画の確定：ベンダーが示す修正適用手順に沿って、検証→本番適用の順で日程を決め、担当者と作業手順を明確化する。更新作業と並行して、影響評価やロールバック手順も整備しておく。
- 暫定策の実施：更新まで時間がかかる場合は、Insights クライアント関連機能の一時停止、アクセス制限、権限見直しなど、実施可能な緩和策を優先適用する。特に、spoke クラスタ側のセキュリティ強化（認証強化、構成見直しなど）を行い、攻撃者による spoke クラスタ侵害のリスクを低減する。
- 証跡の確保：適用前後の設定、バージョン、作業記録、ログ確認結果を残し、監査やインシデント対応に備える。脆弱性対応の経緯を文書化し、再発時の迅速な判断材料とする。
CSRIからの現場アドバイス
実際のペネトレーションテストでは、管理系 API や Web コンソールの入力値チェックが甘い箇所から、意図しないパス指定が通るケースが見つかる。診断報告書でよく指摘されるのが、最新版への更新が運用停止を恐れて後回しになり、脆弱なまま公開範囲だけが広がっている状態だ。今回のようにクラスタ ID やパス要素が十分に検証されずに URL に利用されると、意図しない API エンドポイントへのアクセスを許してしまう危険がある。
例えるなら、建物の中で「関係者以外立入禁止」の扉があるのに、案内板の抜け道から裏口に回れてしまうようなものだ。つまり、決められた場所以外のファイルや API に触れられる可能性がある。放置すると、設定情報や内部データが見られたり、運用が乱されたりする恐れがある。
まず稼働中の製品名とバージョンを棚卸しし、JVN（Japan Vulnerability Notes）が示す影響範囲に当てはまるか確認する。次に保守担当者やベンダーに修正適用の手順と所要時間を依頼し、できる限り早期に検証環境で更新可否を判断する。更新までの間は管理画面や管理系 API の到達経路を絞り、不要な公開を止めるとともに、spoke クラスタ側の防御力を高めることで、悪意ある ClusterID 注入のリスクを低減する。
参照: レッドハットのRed Hat Advanced Cluster Management for Kubernetes等の複数製品におけるパストラバーサルの脆弱性
参考：公式情報・アドバイザリ
- CVE-2026-71475: NVD (NIST) / JVN検索
上記は本記事に関連する公式セキュリティ情報です。詳細は各機関の公式サイトをご確認ください。