Red Hat OpenShift AIに管理者なりすましの穴 CVE-2026-16745、3.5へ更新を

Red Hatの機械学習向け基盤「Red Hat OpenShift AI」の管理画面に、社内のシステムに入り込んだ攻撃者が管理者を含む他人になりすませる欠陥が見つかりました。管理番号はCVE-2026-16745で、危険度は「CVSS 8.8（重要）」と評価されています。

ただし、この欠陥はインターネットから誰でも一発で突けるものではありません。突かれるには「攻撃者がすでにシステムの内側に足がかりを持っていること」が前提になります。逆に言えば、その前提と自分の環境を照らし合わせれば、対象かどうかがはっきり分かります。この記事では、何が起きるのか、誰が対象なのか、対象だった場合に何をすべきかを順番に整理します。

Red Hat OpenShift AIとは何で、なぜ影響が大きいのか

Red Hat OpenShift AI（略してRHOAIとも呼ばれます）は、企業が人工知能（AI）や機械学習のモデルを開発し、そのまま本番で動かすための土台となるソフトウェアです。データの前処理からモデルの学習、公開まで、一連の作業を一つの画面で扱えるようにまとめた製品で、金融・製造・研究機関など、社内に大量のデータを抱える組織で導入が進んでいます。

この基盤は、コンテナと呼ばれる小さな実行環境をたくさん並べて動かす「Kubernetes（クバネティス）」という仕組みの上に載っています。Kubernetesは、多数のプログラムを一つの群れ（クラスタ）としてまとめて管理する土台で、OpenShiftはそれをRed Hatが企業向けに整えたものです。今回問題になったのは、そのOpenShift AIの操作画面である「odh-dashboard」という管理コンソールでした。

導入している組織の数そのものは、一般向けのサービスほど多くありません。しかし一つひとつの現場では、複数のチームや取引先が同じ基盤を共同で使う「相乗り」の形が珍しくありません。この相乗りの環境こそが、今回の欠陥がじわりと効いてくる場所です。

何が起きるのか——本人確認をすり抜けて他人になりすます

今回の欠陥を突かれると、攻撃者は管理コンソールに対して「自分は別の利用者だ」と偽り、その利用者になりすませます。NVDの説明によれば、攻撃者は任意のアクセス用の合言葉（トークン）を送りつけるだけで、管理者を含む「クラスタ内の任意の利用者」になりすませるとされています。

なりすましが成立すると、その先はクラスタ全体の操作窓口である「Kubernetes API」に手が届きます。ここを握られると、勝手なプログラムを動かす、権限をさらに引き上げる、保存されたデータを読み出す、といった行為が可能になります。危険度の評価でも、情報の漏えい・データの改ざん・サービス停止のいずれもが「高」と付けられており、乗っ取られたときの被害の幅広さを示しています。

重要なのは、これがインターネット越しの一撃ではないという点です。攻撃者はまず、クラスタの内側に何らかの足がかりを持っている必要があります。とはいえ、複数のチームが相乗りするような環境では、その足がかりのハードルは決して高くありません。低い権限しか持たないはずの一つのコンテナが、この欠陥を踏み台にして一気にクラスタ全体の主になり得るのです。

攻撃者は誰を狙い、何をするのか

この欠陥を活かせるのは、対象のクラスタの中にすでに一つでも足がかりを持っている攻撃者です。たとえば別の弱点を突いて乗っ取った低権限のコンテナ、外部から持ち込まれた素性の怪しい機械学習ジョブ、あるいは相乗り環境で悪意を持った別チームの利用者など、「クラスタの内側で何かを動かせる立場」の者が想定されます。外から誰でも即座に、というタイプではなく、内部に一歩入り込んだ後の“横移動”や“昇格”の道具として使われる欠陥です。

その相手がすることは、管理コンソールの裏口に直接つなぎ、本人確認用のヘッダに好きな合言葉を書き込んで、管理者になりすますことです。いったん管理者としてクラスタの操作窓口に入れてしまえば、あとは思いのままです。保存された学習データや認証情報を抜き取る、不正なプログラムを常駐させる、そのクラスタを踏み台に社内の別のシステムへ入り込む、といった動きにつながります。

被害の向く先は二方向です。基盤を使ってサービスを提供している企業にとっては、AIの学習に使う機密データや顧客情報が丸ごと危険にさらされます。その基盤の上で動くサービスを利用するエンドユーザーにとっては、自分の情報が知らぬ間に抜き取られる恐れが生じます。だからこそ、次の章で「自分の環境がそもそも対象なのか」をはっきりさせることが大切になります。

あなたの環境は対象か——3つの条件で判定する

危険度はCVSS 8.8と高い一方で、評価の内訳を見ると、攻撃には「低いながらも何らかの権限（PR:L）」が必要とされています。つまり、いくつかの前提がそろって初めて危険になります。Red Hatの勧告を踏まえると、次の3つがすべて当てはまる場合に注意が必要です。

• Red Hat OpenShift AIを運用している——管理画面のodh-dashboardが動いている環境が対象です。OpenShift AIを導入していなければ、この欠陥とは無関係です。
• バージョンが2.25、3.3、3.4のいずれかである——修正版の3.5より前の系列が対象です。すでに3.5以降へ更新済みなら、この件で手を打つ必要はありません。
• クラスタ内に、完全には信頼しきれないプログラムが同居しうる——複数チームや取引先が相乗りする環境、外部から機械学習ジョブを受け入れる環境などが該当します。逆に、単一チームが占有し、動くものすべてを把握・信頼できるクラスタは、成立条件が整いにくい状態です。

3つのうち1つでも外れていれば、この欠陥で即座に乗っ取られる心配は小さくなります。とはいえ、3番目の「信頼できるか」は運用実態に左右されやすく、内部が一つでも侵害されれば前提は崩れます。まずは自組織のOpenShift AIがどのバージョンで動いているかを、運用チームに確認してもらうところから始めてください。

影響を受けるバージョン早見表

自組織のOpenShift AIがどの位置にあるかを、下の表で確認できます。バージョンは、OpenShiftの管理画面やoc getコマンドで確認できるOpenShift AIの導入情報に記載されています。

修正は、開発の大元では2026年5月27日に取り込まれ、製品としてはOpenShift AI 3.5で提供されています。2.25や3.3など古い系列を使い続けている環境については、Red HatのCVEページで各系列向けの更新情報を確認し、自環境に合った手順で対処してください。

なぜ起きたのか——「本人確認のヘッダ」を鵜呑みにした設計

仕組みを平たく説明します。odh-dashboardの裏側で動くプログラム（バックエンド）は、本来なら手前に置かれた「門番」を通してしか触れないはずでした。この門番は、OpenShiftで広く使われるkube-rbac-proxyという部品で、利用者が本物かどうかを確認し、確認できた場合にだけ本人の情報を裏側へ引き渡す役目を担います。

問題は二つ重なりました。一つは、裏側のプログラムが、通信の入口をクラスタ全体に開いた状態（0.0.0.0:8080）で待ち受けていたこと。もう一つは、その裏側が、門番から渡されるはずの本人確認用ヘッダ「x-forwarded-access-token」を、どこから来たのかを確かめずに鵜呑みにしていたことです。この二つがそろった結果、クラスタ内のどのコンテナからでも門番を飛び越えて裏口に直接つなぎ、ヘッダに好きな合言葉を書けばなりすませる状態になっていました。

これは、受け取った情報の「送り主」を確認せずに信用してしまう「通信元の確認漏れ（CWE-346）」という種類の欠陥です。修正は素直で、裏側の待ち受けを自分自身の内側（127.0.0.1）だけに絞り、門番を経由しない直接の接続をそもそも受け付けないようにしました。同じodh-dashboardでは過去にも、内部の合言葉が外部に漏れる別の欠陥（CVE-2026-5483）が2026年4月に修正されており、認証まわりの作り込みが繰り返し課題になっています。Kubernetes基盤の設定の甘さが乗っ取りにつながる構図は、OpenShift本体で見つかった低い権限からの通信乗っ取りとも共通します。

今すぐやるべき対処

前章の3条件に当てはまった場合、対処は次の順で検討します。上から順に優先度が高い対応です。

• OpenShift AIを3.5以降へ更新する——これが根本対処です。3.5では裏側の待ち受けが内側だけに絞られ、門番を飛び越える経路そのものがふさがれています。
• すぐに更新できない場合は、通信を絞って緩和する——Kubernetesの通信制御（NetworkPolicy）で、odh-dashboardの裏側ポートへ他のコンテナから直接つなげないように制限すると、攻撃経路を一時的に塞げます。
• クラスタ内の「信頼できる範囲」を見直す——相乗り環境なら、チームや取引先ごとに実行環境を分ける、外部から持ち込むジョブの権限を最小限に絞る、といった見直しで、そもそも足がかりを作らせない工夫が効きます。
• 門番（kube-rbac-proxy）が正しく効いているかを点検する——認証を担う部品が意図通りに前段に置かれているかを確認し、抜け道がないかを合わせて確かめます。

応急処置としては通信の制限が最も手早く、まずここから着手するのが現実的です。そのうえで、計画的に3.5以降への更新を進めるのが望ましい流れです。自組織のクラスタで動く部品にどんな弱点が潜んでいるかを継続的に洗い出したい場合は、日ごろから設定や権限の見直しを習慣づけておくことが、この種の内部からの昇格を防ぐ近道になります。

この欠陥はAIによる監査で見つかった

今回の欠陥には、もう一つ見逃せない特徴があります。発見したのが外部の研究者ではなく、Red Hatが自社製品を対象に走らせているAIによるセキュリティ監査「Project Glasswing」だという点です。Red Hatの製品セキュリティ部門が、AIにソースコードや構成を点検させる取り組みの中でこの問題を洗い出し、社内の管理番号RHOAIENG-69351として修正につなげました。

AIが人手を介さずに脆弱性を掘り当てる流れは、ここ最近急に現実味を帯びてきています。当サイトでも、AIが発見したApacheのサービス停止の欠陥を取り上げました。今回はさらに一歩進み、AIの開発基盤そのものの穴を、AIが監査して見つけたことになります。守る側がAIを使い始めれば、これまで人手では見落とされてきた設定の甘さが次々と表に出てくる可能性があります。

見方を変えれば、今回の欠陥が実際の攻撃に使われる前に、防御側の点検で先に見つけられたとも言えます。悪用の報告がまだ一件も出ていないのは、その早期発見の成果でもあります。

すでに攻撃は始まっているのか

記事公開の時点では、この欠陥が実際の攻撃に使われたという確認された報告はありません。米政府機関のCISAが公開する「実際に攻撃が確認された欠陥のリスト（KEV）」にも、現時点で載っていません。最新の掲載状況はCISAの攻撃確認リストの日本語まとめで確認できます。

ただし、油断はできません。この欠陥は「クラスタの内側に入り込んだ後」に効くタイプで、外からの侵入と組み合わさったときに一気に被害が広がります。別の弱点で足がかりを作られ、そこからこの欠陥で管理者に化ける、という多段の攻撃は現実的なシナリオです。悪用が確認されていない今のうちに、対象環境は先手で更新や通信制限を済ませておくのが安全です。

これから何に注意すべきか

ここまでを整理します。今回の欠陥は危険度こそ高いものの、インターネットから誰でも突けるものではなく、まず「クラスタの内側に足がかりがあるか」が前提になります。自組織のOpenShift AIが2.25・3.3・3.4のいずれかで、かつ複数チームや外部ジョブが相乗りする環境なら対象です。当てはまる場合は、通信制限で急場をしのぎつつ、計画的に3.5以降への更新を進めてください。

今後の注目点は、古い系列（2.25や3.3）向けの更新情報がどう案内されるか、そして実際の悪用やKEVへの追加があるかどうかです。動きがあれば、この記事に追記していきます。CVE-2026-16745の公式情報とRed Hatの勧告も、あわせて確認しておくと安心です。

参照元

• ▸ NVD - CVE-2026-16745 Detail
• ▸ Red Hat - CVE-2026-16745
• ▸ Red Hat Bugzilla - Bug 2506350（CVE-2026-16745）
• ▸ Red Hat OpenShift AI 製品ページ
• ▸ NVD - CVE-2026-5483（同じodh-dashboardの関連欠陥）