CVE-2025-62593 Ray の RCE 脆弱性｜KEV 追加と影響確認

はじめに

Ray は分散処理と AI ワークロードの基盤として広く使われています。その Ray に存在するリモートコード実行の脆弱性 CVE-2025-62593 が、2026 年 8 月 17 日に CISA の Known Exploited Vulnerabilities Catalog（KEV）へ追加されました。脆弱性そのものは 2025 年 11 月に公開されたもので、新規に発見されたものではありません。今回は「既知の脆弱性に実際の悪用が確認された」という位置づけの更新です。

この脆弱性で判断を誤りやすいのが影響範囲です。Ray Dashboard をインターネットに公開していないから対象外、という整理では不十分になります。

結論として、影響範囲は GitHub Security Advisory が示す Ray 2.52.0 未満が基準となり、対応の基本は現行の安定版への更新です。攻撃はブラウザーを経由して成立するため、Ray が localhost や社内ネットワークにしか存在しない場合でも対象になり得ます。Firewall や Security Group での公開制御だけでは、今回の攻撃モデルを説明しきれない点が実務上のポイントです。

CVE-2025-62593 の概要と時系列

CVE-2025-62593 は、Ray Dashboard が備えるブラウザー由来リクエストの遮断処理が不十分であることに起因する、リモートコード実行の脆弱性です。認証を持たないジョブ投入系エンドポイントに対して、ブラウザーを介したリクエストが到達し得ます。

一次情報で確認できる基本情報

CVSS ベクターのうち、実務上の読みどころは UI:P（User Interaction: Passive）です。標的となる開発者に特別な操作を求めず、Web ページを開くという通常の行為の範囲で成立し得ることを示しています。PR:N と合わせると、事前の権限取得を前提としない攻撃モデルであることが読み取れます。

公開から KEV 追加までの流れ

時系列を整理すると次のようになります。バージョンのリリース日は Ray 公式リリースページと PyPI の公開日時に基づきます。

1. 2025 年 11 月 21 日: Ray 2.52.0 リリース（Token Authentication を導入）
2. 2025 年 11 月 26 日: CVE-2025-62593 と GHSA-q279-jhrf-cc6v が公開
3. 2025 年 11 月 28 日: Ray 2.52.1 リリース（ブラウザー判定処理の強化）
4. 2025 年 11 月 29 日: Ray 2.51.2 リリース（2.51 系への修正取り込み）
5. 2026 年 8 月 17 日: CISA が KEV へ追加

修正版が公開されてから KEV 追加まで約 9 か月が経過しています。開発端末や検証環境の Ray は更新が後回しになりやすく、この期間に取り残された環境が残っている可能性があります。

CISA KEV への追加内容

KEV カタログでは、Ray-Project Ray のコードインジェクション脆弱性としてリモートコード実行につながる旨が記載されています。

参考: CISA Known Exploited Vulnerabilities Catalog
“Ray-Project Ray contains a code injection vulnerability that could allow remote code execution.”
（Ray-Project Ray には、リモートコード実行を許し得るコードインジェクションの脆弱性が存在する）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

KEV カタログ上の Due Date は 2026 年 8 月 20 日です。これは BOD 26-04 に基づく連邦民間行政機関（FCEB）向けの期限であり、民間企業に法的な適用があるものではありません。ただし、追加から 3 日という設定は、CISA が短い対応期間を要すると判断したことを示す材料になります。

BOD 26-04 では、対応期限を次の 4 つの変数の組み合わせから導出します。

このうち KEV Status、Exploit Automation、Technical Impact の 3 つは CISA が Vulnrichment を通じて公開しており、CVE レコードの ADP コンテナで確認できます。CVE-2025-62593 には SSVC の判定値として Exploitation: active、Automatable: no、Technical Impact: total が付与されています。残る Asset Exposure は各組織が自環境で判定する変数です。

期限の起点となる変数のうち、外部から与えられないのは Asset Exposure だけという構造になるため、連邦機関以外でも、自組織の Ray が外部から到達可能かどうかを先に確定させると優先度を判断しやすくなります。ただし後述するとおり、この脆弱性では Asset Exposure が「いいえ」であっても影響判定が終わらない点に注意が必要です。

なお、悪用状況については CISA が公開している範囲を超えた解釈は避けるべきです。CVE レコードには第三者調査として Bitsight のボットネット分析が参照として付与されています。同社は CVE-2025-62593 を対象とする探索行為を観測した一方で、観測されたエクスプロイト実装の User-Agent が Mozilla で始まる文字列であったため、Ray 側の遮断処理に阻まれて機能しない可能性がある、とも述べています。無差別スキャンによる試行と、次章で扱う開発者を標的とした攻撃モデルは、性質が異なるものとして分けて考えることをおすすめします。

なぜインターネット非公開の Ray も注意が必要なのか

この脆弱性の理解で最も重要な部分です。単純な「Ray Dashboard をインターネット公開している場合の RCE」として整理すると、影響判定を誤ります。

遮断処理が User-Agent に依存していた

Ray Dashboard は、ブラウザーからのリクエストを User-Agent が Mozilla で始まるかどうかで判定し、POST や PUT を拒否する実装になっていました。Advisory は、この判定が弱い前提に立っていたと説明しています。fetch 仕様では User-Agent ヘッダーの変更が許容されるため、判定を回避できます。

Firefox と Safari は仕様どおり fetch API から User-Agent を変更できます。Chrome は仕様から外れた挙動のために変更できず、結果としてこの経路では影響を受けないと Advisory は記載しています。ブラウザーの実装差がそのまま攻撃条件になっている点が、この脆弱性の特徴です。

DNS rebinding でブラウザーが仲介役になる

User-Agent の回避だけでは、外部の Web サイトから localhost や社内アドレスへリクエストは届きません。ここで DNS rebinding が組み合わされます。攻撃者が用意したドメインの名前解決結果を、途中で内部アドレスへ切り替えることで、ブラウザーは「同じサイトへのアクセス」として内部の Ray へリクエストを送ります。

開発者が悪意ある Web サイトを開いた、あるいは不正な広告を表示しただけで、そのブラウザーが内部の Ray に到達する経路になり得るというのが、この攻撃モデルの本質です。Advisory は、ネットワーク的に隣接する Ray インスタンスへの攻撃にも利用され得ると明示しています。

参考: GHSA-q279-jhrf-cc6v（ray-project/ray Security Advisory）
“This attack can also be leveraged to attack network-adjacent instance of ray”
（この攻撃は、ネットワーク的に隣接する Ray インスタンスへの攻撃にも利用され得る）
https://github.com/ray-project/ray/security/advisories/GHSA-q279-jhrf-cc6v

経路を図示すると次のようになります。

外部公開制御だけでは説明しきれない理由

Firewall、Security Group、Kubernetes Ingress といった境界制御は、インターネット側から Ray Dashboard への直接アクセスを遮断します。今回の攻撃モデルでは、リクエストの送信元が開発者自身のブラウザー、つまり境界の内側です。境界制御は外部からの直接到達を防ぐうえで有効ですが、内側から内側へ向かうこの経路を前提に設計されているとは限りません。

Advisory は、一部のブラウザーが DNS rebinding への対策を進めていることにも触れつつ、以前の取り組みが取り下げられた経緯があるため、更新を多層防御として推奨する旨を記載しています。ブラウザー側の緩和策に依存せず、Ray 自体を更新する方針が妥当です。

なお、企業ネットワークの中には DNS rebinding を遮断する構成もあります。ただし、これは環境ごとに異なる前提条件であり、遮断されているかどうかを確認せずに安全と判断することはおすすめしません。

自分の環境が影響を受けるか確認する

ここからは実際の確認手順です。判定に必要な観点を順に押さえます。

影響判定フロー

次の順で確認すると、判断材料が揃います。

観点として整理すると次の 8 点になります。

1. Ray を利用しているか（開発端末、検証環境、AI 基盤、CI を含む）
2. Ray のバージョンはいくつか
3. Ray Dashboard / Jobs API がどのアドレス・ポートで待ち受けているか
4. ブラウザーが動作する端末から、その待ち受け先へ到達できるか
5. 到達し得るのは開発端末自身の localhost か、同一 LAN や社内ネットワーク上の Ray か
6. 開発者が Firefox / Safari から外部 Web サイトへアクセスする環境か
7. 対象バージョンの場合、更新は可能か
8. 更新後に Token Authentication やネットワーク制御を追加するか

観点 5 と 6 が今回の判定で外せない部分です。インターネット公開の有無だけで対象外と判断しないことが、この脆弱性への向き合い方になります。

観点 4 が「いいえ」、つまりブラウザーが動作する端末からいずれの Ray Dashboard へも到達できない場合は、この経路での到達性は低いと判断できます。ただしこれは対象外を意味しません。判定はその時点の待ち受け設定とネットワーク構成に依存しており、ray startのオプション変更、ポートフォワードの一時的な使用、開発端末へのローカル Ray の追加インストールなどで前提は容易に変わります。到達性が低いと判断した場合も、更新は計画に組み込み、起動条件が変わっていないかを定期的に確認する扱いをおすすめします。

Ray のバージョンを確認する

インストール済みの Ray は、パッケージ情報またはモジュール属性から確認できます。

# pip のパッケージ情報から確認
pip show ray

# Python から確認
python -c "import ray; print(ray.__version__)"

コンテナや Kubernetes で稼働している場合は、イメージタグだけで判断せず、実際に動作しているコンテナ内で確認すると確実です。

# KubeRay の場合の例（Pod 名は環境に合わせて置き換え）
kubectl exec <ray-head-pod> -- pip show ray

開発端末が複数ある場合は、仮想環境ごとに Ray が入っていることがあります。プロジェクト単位の仮想環境も確認対象に含めることをおすすめします。

Dashboard と Jobs API の到達性を確認する

Ray Dashboard は、ヘッドノードのポート 8265 で動作します。ポートは --dashboard-port（CLI）または dashboard_port（ray.init()）で変更できるため、既定値だけを前提にしない方が安全です。

参考: Configuring and Managing Ray Dashboard（Ray 公式ドキュメント）
“The Ray Dashboard provides read and write access to the Ray Cluster.”
（Ray Dashboard は Ray クラスターに対する読み取りと書き込みのアクセスを提供する）
https://docs.ray.io/en/latest/cluster/configure-manage-dashboard.html

待ち受け状況は OS 側のコマンドで確認します。

# Linux
ss -lntp | grep 8265

# macOS
lsof -nP -iTCP:8265 -sTCP:LISTEN

ここで確認したいのは、ポートが開いているかどうかだけではありません。127.0.0.1:8265 で待ち受けているのか、0.0.0.0:8265 で待ち受けているのかによって、到達し得る範囲が変わります。前者であれば同一端末のブラウザーが、後者であれば同一ネットワーク上の端末のブラウザーが、それぞれ仲介役になり得ます。どちらの場合も、インターネットからの直接到達性とは別の問題として扱う必要があります。

KubeRay の場合、Dashboard は <RayCluster name>-head-svc という Service 経由で提供されます。クラスター内からの到達性と、Ingress による外部公開の有無を分けて確認してください。公式ドキュメントも、Ingress は信頼できる送信元だけに限定するよう記載しています。

なお、Ray Dashboard は --include-dashboard=False（CLI）や include_dashboard=False（ray.init()）で無効化できます。ただし KubeRay では RayJob や RayService が Dashboard に依存するため、無効化は推奨されないとドキュメントに明記されています。また、Dashboard の停止が今回の経路をすべて塞ぐかどうかは公式情報からは確認できません。無効化を対策の中心に据えるのではなく、更新を基本とする整理をおすすめします。

Ray のアップデートと対象バージョンの整理

対応の中心は更新です。ただし、バージョン表記が一次情報の間で単純に一致していないため、順を追って整理します。

2.51.2 / 2.52.0 / 2.52.1 の関係

GitHub Security Advisory の記載は次のとおりです。

• Affected versions: < 2.52.0
• Patched versions: 2.52.0

一方、Ray のリリースノートには 2.52.1 と 2.51.2 にも CVE-2025-62593 に関する記述があります。

参考: Release Ray-2.51.2（ray-project/ray）
“Fix for CVE-2025-62593: reject Sec-Fetch-* other browser-specific headers in dashboard browser rejection logic”
（CVE-2025-62593 への修正: Dashboard のブラウザー遮断処理で Sec-Fetch-* などブラウザー固有のヘッダーを拒否する）
https://github.com/ray-project/ray/releases/tag/ray-2.51.2

参考: Release Ray-2.52.1（ray-project/ray）
“More robust handling for CVE-2025-62593: test for more browser-specific headers”
（CVE-2025-62593 に対するより堅牢な処理: より多くのブラウザー固有ヘッダーを検査する）
https://github.com/ray-project/ray/releases/tag/ray-2.52.1

リリース日を並べると、2.52.0 が 2025 年 11 月 21 日、2.52.1 が 11 月 28 日、2.51.2 が 11 月 29 日です。2.51.2 は 2.52 系より後に公開されており、2.51 系を利用している環境向けに修正が取り込まれたものと読めます。

ただし、GitHub Security Advisory の Affected / Patched の記載はこの状況を反映しておらず、< 2.52.0 のままです。したがって、2.51.2 を安全なバージョンとして断定することは避け、影響範囲の判定には Advisory の < 2.52.0 を基準に使うという整理が安全側になります。2.51.2 の位置づけについては、Ray 側の一次情報が明示的に整理していないため、本記事でも断定しません。

更新先の考え方

更新先を 2.52.0 だけに固定する必要はありません。Advisory は 2.52.0 以降への更新を修正方法として案内しており、その後もブラウザー遮断処理の強化が続いています。実務上は、現在利用可能な安定版へ更新する方針が扱いやすくなります。

本記事の執筆時点では、PyPI 上の最新安定版は Ray 2.57.0（2026 年 8 月 11 日公開）です。更新前に、公式リリースページで現行の安定版を確認してください。

# 最新の安定版へ更新する場合
pip install -U "ray[default]"

# バージョンを指定して更新する場合（例）
pip install "ray[default]==2.57.0"

Ray はマイナーバージョン間で既定の挙動が変わることがあります。2.52.0 では Python 3.9 向け wheel の提供が終了しており、実行環境の Python バージョンによっては更新前に確認が必要です。本番の AI 基盤で大きくバージョンを上げる場合は、検証環境で依存ライブラリの整合を確認してから展開する流れをおすすめします。開発端末や検証環境については、更新の影響が小さいことが多いため、先行して対応する価値があります。

KubeRay やマネージドサービスを利用している場合は、イメージタグの更新とあわせて、ワーカーノードを含めた全ノードのバージョンを揃えてください。

更新後に検討したい Token Authentication とアクセス制御

更新が済んだ後の追加ハードニングとして、Ray 2.52.0 で導入された Token Authentication があります。

Token Authentication の位置づけ

Ray はこれまで、Jobs API を含む主要なエンドポイントに認証機構を持っていませんでした。2.52.0 で、Dashboard、CLI、API クライアント、内部通信を対象としたトークン認証が追加されています。

参考: Release Ray-2.52.0（ray-project/ray）
“Token authentication is initially off by default.”
（トークン認証は当初、既定では無効）
https://github.com/ray-project/ray/releases/tag/ray-2.52.0

既定で無効である点は、執筆時点の公式ドキュメント（Ray 2.57.0 版）でも維持されています。

参考: Ray token authentication（Ray 公式ドキュメント）
“Authentication is disabled by default in Ray 2.52.0.”
（Ray 2.52.0 では認証は既定で無効）
https://docs.ray.io/en/latest/ray-security/token-auth.html

同ドキュメントには、将来のリリースで既定有効化を計画している旨も記載されています。つまり、2.52.0 以降へ更新しただけではトークン認証は有効にならず、明示的な設定が必要です。

この既定値をめぐっては補足があります。トークン認証が既定で無効であることを脆弱性として登録した CVE-2025-34351 が 2025 年 11 月に公開されましたが、CVE レコードは 2025 年 12 月 2 日に REJECTED となり、既存の CVE-2023-48022 に置き換えられています。認証を持たないという設計自体は、以前から CVE-2023-48022 として扱われてきた論点である、という整理になります。

重要なのは、Token Authentication を更新の代わりに使わないことです。今回の脆弱性の修正は Dashboard のブラウザー遮断処理側にあります。公式のセキュリティドキュメントも、トークン認証は統制されたネットワーク環境への配置を置き換えるものではないと位置づけています。

有効化の手順

有効化は環境変数 RAY_AUTH_MODE=tokenをクラスター起動前に設定します。トークンの生成と配置方法は、起動方法によって異なります。

ローカル開発で ray startを使う場合は、事前にトークンを生成します。

export RAY_AUTH_MODE=token
ray get-auth-token --generate
ray start --head

ray.init()でローカルインスタンスを起動する場合は、RAY_AUTH_MODE=tokenを設定しておくと、トークンが存在しなければ自動生成されます。

複数ノードで ray startを実行する自己管理型のクラスターでは、生成したトークンを全ノードへ配布したうえで、各ノードで環境変数を設定します。

scp ~/.ray/auth_token user@node1:~/.ray/auth_token
ssh user@node1 "RAY_AUTH_MODE=token ray start --head"

トークンの参照順序は、RAY_AUTH_TOKEN、RAY_AUTH_TOKEN_PATH、既定パス ~/.ray/auth_tokenの順です。公式ドキュメントは、環境変数へ直接値を設定するよりも、ファイルとパス指定を使う方法を推奨しています。

KubeRay については、トークン認証の設定手順が別途用意されています。KubeRay v1.5.1 以降では Ray コンテナへの環境変数の自動設定に対応しており、それ以前のバージョンでは Kubernetes Secret を作成して RAY_AUTH_MODEと RAY_AUTH_TOKENを設定する手順が案内されています。詳細は公式の KubeRay 向けガイド（https://docs.ray.io/en/latest/cluster/kubernetes/user-guides/kuberay-auth.html ）を参照してください。

トークンは HTTP ヘッダーとして送信されるため、暗号化されていない http 通信では平文で流れます。公式ドキュメントも、ネットワーク越しに Ray クラスターを公開する場合は SSH ポートフォワード、TLS 終端プロキシ、VPN などの暗号化を併用するよう案内しています。トークンには有効期限がなく、削除して再生成するまで有効である点も運用上の注意点です。

更新後に確認しておきたい項目

更新とハードニングの後、次の項目を確認しておくと状態を把握しやすくなります。

• 全ノードの Ray バージョンが揃っているか（ヘッドとワーカーの取り違えが起きやすい箇所）
• Dashboard の待ち受けアドレスが意図したものか（127.0.0.1か 0.0.0.0か）
• RAY_AUTH_MODEの設定がクラスター全体で一致しているか
• トークンファイルの権限が適切か、リポジトリへ混入していないか
• Ingress、Security Group、Firewall のルールが現状の構成と整合しているか
• 開発端末のブラウザーが最新版へ更新されているか

侵害の有無を確認する場合は、確認した範囲を記録に残す形を取ると、後から判断根拠を追えます。具体的には、Dashboard の Jobs 画面や Ray Jobs CLI で想定外のジョブ投入履歴が残っていないかを確認します。コマンドの詳細は公式の CLI リファレンス（https://docs.ray.io/en/latest/cluster/running-applications/job-submission/cli.html ）を参照してください。

ただし、Jobs 履歴の確認はあくまで補助的な手段であり、痕跡が見つからなかったことをもって侵害を否定することはできません。Ray Dashboard は開発・デバッグ向けの位置づけで、クラスターを終了すると UI と内部データが参照できなくなる旨が公式ドキュメントに記載されています。開発端末で起動と停止を繰り返す使い方では、履歴が残っていないこと自体が通常の状態です。また、ジョブとして実行されたコードがその後に何を行ったかは、Ray の履歴だけでは追えません。

記録としては「どのログを、どの期間、どの範囲で確認したか」と「確認できなかった範囲はどこか」を併記する形が実用的です。ログの保存期間が短く該当期間をカバーできなかった場合は、その事実をそのまま残しておくと、後続の判断で無用な再調査を避けられます。実環境での確認を進める場合は、Ray の履歴に加えて、対象端末やノードの EDR、プロキシ、DNS、認証ログなど、コード実行後の挙動を捉え得るログとあわせて確認する流れが現実的です。

継続的な監視という観点では、Ray が Dashboard の API エンドポイントごとに Prometheus メトリクスを出力している点が利用できます。ray_dashboard_api_requests_count_requests_totalはエンドポイント、メソッド、HTTP ステータスでタグ付けされるため、ジョブ投入系エンドポイントへのリクエスト傾向を可視化する材料になります。

まとめ

CVE-2025-62593 は 2025 年 11 月に公開された Ray のリモートコード実行の脆弱性で、2026 年 8 月 17 日に CISA KEV へ追加されました。攻撃はブラウザーを仲介役として成立するため、Ray Dashboard をインターネットに公開していない環境でも影響判定の対象になります。対応の基本は現行の安定版への更新であり、Token Authentication はその後の追加対策として位置づけられます。

• CVE-2025-62593 の KEV 追加日は 2026 年 8 月 17 日
• 影響範囲の基準は GitHub Security Advisory の 2.52.0 未満
• Firefox と Safari では fetch から User-Agent を変更可能
• DNS rebinding により localhost や社内の Ray へも到達し得る経路
• 境界制御だけでは今回の攻撃モデルを説明しきれない構造
• 2.51.2 の位置づけは一次情報で確定できず、断定は避ける整理
• Token Authentication は既定で無効、更新の代替ではない位置づけ

以上、最後までお読みいただきありがとうございました。