OpenShiftに脆弱性 CVE-2026-1784、低い権限でクラスターの通信を乗っ取り

Red Hatの企業向けコンテナ基盤「OpenShift」に、アプリの公開設定（Route）に細工をすると、入口で通信を捌く共有ルーターの設定そのものに余計な指示を紛れ込ませられる欠陥（CVE-2026-1784）が公表されました。危険度を示すCVSSは10点満点中8.8（高）。一つのクラスターを複数の部署や取引先で共有している環境では、自分の領域にしか権限を持たない利用者が、他のアプリ宛ての通信に手を出せてしまう恐れがあります。

OpenShiftの「Route（ルート）」は、クラスターの中で動くアプリを、外から見えるURL（サブドメインとパス）で公開するための設定です。この設定は、クラスターの入口に立つ共有のロードバランサ（ルーター）に取り込まれ、内部ではHAProxyという定番のソフトの設定ファイルへ変換されて動きます。今回は、その設定に変換する前のチェックが甘く、利用者が指定する値を使って設定ファイルに割り込めてしまう、というのが欠陥の中身でございます。本記事では、何が起きるのか、自社が影響を受けるのか、いま何をすべきかを順番に整理します。

欠陥の概要

最初に要点を一覧にします。最大の特徴は、攻撃の出発点が「ネット越しに誰でも」ではなく、クラスターにログインできて自分の領域にルートを作れる程度の権限を持つ利用者である点です。だからこそ、多数のチームで一つのクラスターを共有している環境ほど効いてきます。

CVSSが最高の10.0ではなく8.8にとどまっているのは、攻撃に「クラスターへのログイン」と「ルートを作れる権限」という前提が要るからです。ネット越しに見知らぬ第三者が一方的に踏み込めるタイプではありません。ただし、その前提は共有クラスターでは日常的に満たされます。開発者が自分の名前空間（割り当てられた作業領域）にルートを作るのは、ごく普通の運用だからです。影響範囲が自分の領域を越えて広がる点（S:C＝スコープ変更）も評価され、CVSSは高ランクの8.8が付きました。

受付の案内板を書き換えられた時、通信はどこへ消えるのか

厄介なのは、踏み台が管理者権限ではなく、開発者が普段から持つ「アプリを公開する」権限だという点です。ここに値を付けるのは、同じクラスターに同居する悪意ある委託先の作業者、盗んだ開発者アカウントで入り込んだ初期アクセス業者、企業のコンテナ基盤を狙うランサムウェア集団です。彼らが手にするのは、隣の部署のアプリに流れ込むログイン用のIDとパスワード、業務データ、APIトークンです。細工したルート定義が共有ルーターに読み込まれた瞬間、別のアプリ宛ての通信が、攻撃者が用意した偽の宛先へ静かに付け替えられてしまいます。

抜き取った先は一段では止まりません。受け取ったIDとパスワードで正規利用者になりすまし、別のサーバーやデータベースへ横に広がります。盗んだ認証情報はダークウェブで転売され、買い手はクラスター全体を暗号化し、抜いた顧客情報の公開をちらつかせる二重恐喝に持ち込みます。取引先システムを相乗りさせた基盤なら、被害は運用元一社では収まりません。

後始末を背負うのは、クラスターを運用するプラットフォーム部門と、構築を請け負ったSIer、そして経営です。通信の盗み見で個人情報が漏れれば、個人情報保護委員会への報告と本人通知の義務が生じ、損害賠償や信用の失墜も残ります。CVSS 8.8という数字に表れないのは、共有基盤の「入口」が信用を失えば全テナントが疑われ、復旧時に全社のサービスを止めて検証する羽目になる運用コストです。権限設計を引き締め、修正版を当てられるかが、いま当事者の安全を分けます。

そもそもOpenShiftの「Route」と「ルーター」とは何か

OpenShiftは、Red Hatが提供する企業向けの「Kubernetes（クバネティス）」基盤です。Kubernetesは、アプリを小さな箱（コンテナ）に詰めて大量に動かすための仕組みで、OpenShiftはそれを企業が使いやすいように整えた製品でございます。大企業では、一つの大きなクラスター（サーバー群）を複数の部署や取引先で分け合って使う「マルチテナント」運用が一般的で、各チームには「名前空間」と呼ばれる自分専用の作業領域が割り当てられます。

その中で「Route（ルート）」は、クラスターの内側で動くアプリを、外部からアクセスできるURLで公開するためのOpenShift独自の設定です。「このアドレスのこのパスに来たアクセスは、このアプリへ渡す」という案内を、利用者が spec.host や spec.path といった項目で指定します。開発者が自分のアプリを世に出すとき、ごく当たり前に書く設定でございます。

このルートの案内を実際にさばくのが「ルーター」で、クラスターの入口に立つ全テナント共用のロードバランサです。その正体は定番のソフトHAProxyで、各テナントが作ったルートは、すべて一つのHAProxy設定ファイルにまとめて書き込まれます。つまり、ルートに書いた値は、みんなで共有している「受付の案内板」に転記される、という関係でございます。だからこそ、その転記の前のチェックが甘いと、案内板に余計な指示を紛れ込ませられてしまうのです。

CVE-2026-1784の中身：spec.pathの検証不備でHAProxy設定に割り込み

NVD（米国の脆弱性データベース）とRed Hatの説明によると、問題はルートの spec.path という項目にあります。NVDはこの欠陥を「Route文書の spec.path に対して行われるチェックが不十分で、HAProxy設定の制御された注入（controlled injection）を許し得る」と記しています。本来 spec.path は「このパスに来たアクセスを渡す」という単なる経路指定の文字列ですが、その中身を厳しく検証していなかったため、設定ファイルへ転記される際に、経路指定として意図しない指示を割り込ませられてしまう、というものです。

分類は CWE-15（外部からの設定値の操作）。利用者が入力する値が、システムの設定をそのまま左右してしまう類の欠陥です。共有ルーターの設定に割り込めるということは、自分の名前空間に閉じているはずの設定が、他テナント宛ての通信の扱いにまで影響を及ぼし得ることを意味します。CVSSの内訳 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H のうち、S:C（スコープ変更）はまさにこの「自分の領域を越えて影響が広がる」性質を、C:H/I:H/A:Hは通信内容の盗み見・改ざん・サービス停止のいずれもが起こり得ることを示しています。

対象はRed Hat OpenShift Container Platform 4です。Red Hatはサポート対象の4.x系それぞれに対して、修正を含む更新（errata／RHSA）を順次公開しています。利用しているバージョンに対応する修正の有無と具体的な番号は、Red Hat公式のCVEページで確認するのが確実でございます。なお、本件はRed Hat自身が発見・報告したもので、外部からの不正アクセスを受けて発覚した事案ではありません。

悪用は確認されているのか

現時点で分かっていることと、まだ確認できていないことを分けて整理します。

自社が影響を受けるかの早見表

同じOpenShiftでも、クラスターの使い方と利用者への権限の配り方でリスクの高さが変わります。下の表で自社の状況を当てはめてください。

最も注意すべきは、開発者や委託先に「自分の名前空間にルートを作る」権限を広く配っている共有クラスターです。クラウド上のマネージド版（Red HatのROSAやMicrosoftのARO等）を使っている場合は、基盤側の修正は提供事業者が行うため、各社のセキュリティ告知で対応状況を確認するのが早道でございます。

情報システム部門がいま確認すべきこと

最優先は、利用しているOpenShiftのバージョンに対応する修正errataの適用です。Red Hat公式のCVEページで自社のバージョン向けの更新が出ているかを確認し、出ていれば保守計画に沿って適用してください。すぐに更新できない事情がある場合は、暫定の守りとして、誰がルートを作成・変更できるのかを見直すのが有効です。本当にその権限が必要な利用者だけに絞り、委託先や一時的なアカウントに広く配っていないかを点検します。

あわせて、共有ルーターのHAProxy設定や、ルートの作成・変更の操作ログ（監査ログ）に、見覚えのない spec.path の値や不自然な経路指定が紛れていないかを点検すると安心です。マルチテナントで運用している組織は、これを機に「一つのクラスターをどこまで分け合うか」「テナント同士をどこで隔てるか」という設計そのものを見直す良い機会でございます。国内で広く使われる製品の脆弱性をまとめて追いたい場合は、2026年上半期の重大な脆弱性まとめもあわせて確認してください。

なお、同じ時期にはアプリ基盤の「入口」を狙う欠陥が続いています。認証サーバーから署名鍵が漏れたCloud FoundryのCVE-2026-40965もその一つで、共有基盤の根っこを守ることの重みが増しています。

よくある質問

まとめ

OpenShiftで見つかったCVE-2026-1784は、アプリの公開設定（Route）の spec.path のチェックが甘く、入口で通信を捌く共有ルーターのHAProxy設定に余計な指示を割り込ませられる欠陥です。攻撃には「クラスター利用者でルートを作れる権限」という前提が要るため、CVSSは最高ではなく8.8ですが、その前提は複数チームでクラスターを共有する環境では日常的に満たされます。割り込みが成立すると、他テナント宛ての通信を盗み見たり、別の宛先へ付け替えたりされる恐れがあります。対象はOpenShift Container Platform 4で、Red Hatが4.x系に修正errataを提供しています。まず自社のバージョン向けの修正を適用し、すぐに更新できない場合は、ルートを作成・変更できる権限の棚卸しから着手してください。

参照元

• ▸NVD - CVE-2026-1784（OpenShift Route spec.path / HAProxy設定の注入）
• ▸Red Hat - CVE-2026-1784（影響バージョンと修正errata）
• ▸Red Hat Bugzilla #2436075
• ▸Red Hat Docs - Configuring Routes（OpenShift 4.20）
• ▸GitHub - openshift/router（HAProxyベースのルーター）
• ▸HAProxy 公式サイト