Ray脆弱性が悪用中、開発者端末がRCE標的に

【更新 2026-08-19】本記事を見直し、修正しました。主な修正点：Google Cloudの「Vertex AI」が2026年に「Gemini Enterprise Agent Platform」へ改称され、公式ドキュメント上の名称も「Ray on Agent Platform」に変わっているため、本文の該当箇所と出典リンク（URL含む）を現行の名称に更新しました。

AI・機械学習の分散実行フレームワーク「Ray」の重大な脆弱性（CVE-2025-62593）が、実際の攻撃で悪用されていることが確認されました。米CISAは2026年8月17日にこの脆弱性を「悪用が確認された脆弱性カタログ（KEV）」へ追加し、米連邦政府機関に対して2026年8月20日までという短い期限で対処を求めています。

狙われるのは、インターネットに公開されたサーバではありません。Rayを動かしている開発者・データ分析担当者の端末そのものです。悪意あるWebサイトを開いた、あるいは不正広告を表示しただけで、その端末で任意のコードを実行される可能性があります。ダッシュボードをlocalhostにしか開いていなくても防げません。対処はRay 2.52.0以降への更新です。

この記事でわかること

• Rayとは何で、自社のどこで動いている可能性があるか
• 「外部公開していないのになぜ攻撃されるのか」という攻撃の仕組み（DNSリバインディング）
• Rayが認証を持たない設計だった経緯と、2.52.0で追加された認証が既定では無効である事実
• 修正版の公開から悪用確認（KEV追加）まで約9か月かかった時系列
• 自社に該当するかを確認する具体的な方法

Rayとは何か──「うちは使っていない」が通じにくい理由

Rayとは、Pythonで書いたAI・機械学習の処理を、複数のCPU・GPU・サーバへ分散して実行するためのオープンソースのフレームワークです。開発元はAnyscale社で、pip（pip install ray）で導入します。

使うのは主に、社内のAI開発チームやデータ分析チームです。大規模言語モデル（LLM）の学習・推論、大量データの前処理、ハイパーパラメータ探索など「1台では終わらない計算」を回す場面で選ばれます。情シスが調達・導入したものではないことがほとんどです。

問題は、Rayを名指しで導入した覚えがなくても動いていることがある点です。一次情報で確認できる範囲でも、次のような形で組み込まれています。

なお今回の攻撃経路は後述のとおりブラウザを起点とするローカル／社内向けの攻撃なので、マネージドサービス上のクラスタが直ちに同じ形で狙われるわけではありません。ただし「該当バージョンがどこで動いているか」の棚卸しは、いずれにせよ必要です。

何が起きたのか──CVE-2025-62593がKEVに追加

CISAは2026年8月17日付でKEVカタログを更新し、CVE-2025-62593を「Ray-Project Ray Code Injection Vulnerability」として登録しました。KEVは「実際の攻撃での悪用が確認された」ものだけを載せるカタログであり、掲載自体が悪用の証拠になります。

CVSSはv3.1とv4.0で評価が割れている

スコアは評価バージョンによって大きく異なります。この差自体が、この脆弱性の性質を表しています。

v3.1はS:U（スコープ変更なし）で、影響を脆弱なコンポーネント自身に限って計算します。一方v4.0は後続システムへの影響（SC／SI／SA）を独立して評価し、ここが3項目とも「H」で立っています。これは「食われるのはRayだけで終わらない」ことを評価側が認めているという意味です。スコアだけを自動取り込みして「8.8だから来月の定例で」と判断すると、この構造が見えなくなります。

外部公開していないのに、なぜ攻撃が成立するのか

短く答えると、攻撃者はネットワーク越しにRayを叩くのではなく、開発者のブラウザにRayを叩かせるからです。

Rayのダッシュボードは既定で localhost:8265（--dashboard-host の既定値はlocalhost、--dashboard-port の既定値は8265）で待ち受けます。ジョブ投入API /api/jobs/ にPOSTすれば、そのジョブとして任意のシェルコマンドが実行されます。ここに認証はありません。

Ray側は「ブラウザからのPOSTを拒否する」という防御を入れていました。しかしその判定は、User-Agentヘッダが文字列「Mozilla」で始まるかどうかだけを見るものでした。アドバイザリはこの前提の誤りを明確に説明しています。

• fetch APIの仕様では、FirefoxとSafariはUser-Agentヘッダを書き換えられる。よって「Mozilla判定」は素通りできる
• Chromeは書き換えられないため影響を受けない。ただしそれは仕様への準拠ではなくChrome側の既知の不具合による偶然だとアドバイザリは述べている
• これをDNSリバインディング攻撃と組み合わせると、悪意あるサイトを開いたブラウザが端末内のRayへPOSTできる

実証コードはDNSリバインディング用の公開ツール（nccgroup/singularity）にRay向けペイロードとして取り込まれており、特別な足場は要りません。開発者が悪意あるサイトを踏む、あるいは不正広告（マルバタイジング）を表示するだけで成立します。

被害は踏んだ端末だけで終わらない

アドバイザリはもう一段踏み込んで、この攻撃が「ブラウザを confused deputy（混乱した代理人）として使い、社内ネットワーク上の別のRayインスタンスを攻撃する」ためにも使えると明記しています。社外から直接は届かない社内のRayクラスタが、社内にいる開発者のブラウザ経由で叩かれる、という構図です。先ほどのCVSS v4.0で SC:H/SI:H/SA:H が立っている理由がここにあります。

「認証がないのは仕様」という長年の設計方針

この脆弱性を理解するうえで外せないのが、Rayが重要なエンドポイントに認証を実装しないという方針を長く取ってきたことです。アドバイザリ自身が「この長年の決定が、またしても深刻な脆弱性につながった」と述べています。

実際、ジョブ投入API経由の任意コード実行はCVE-2023-48022（CVSS v3.1で9.8）として2023年に採番されていますが、NVD上では現在もDisputed（係争中）の扱いです。ベンダーは「Rayは厳格に制御されたネットワーク環境外での利用を想定しておらず、この報告は的外れである」という趣旨の反論をしています。

今回のCVE-2025-62593が重いのは、この反論の前提そのものを崩している点です。「厳格に制御されたネットワークの内側」にあるRayが、そこにいる人のブラウザ経由で外から叩かれるのですから、ネットワーク境界に頼った安全確保は成立しません。

2.52.0で認証機能が入ったが、既定では無効

Ray 2.52.0では今回の修正に加えて、ようやくトークン認証が追加されました。ただし公式ドキュメントは「Ray 2.52.0では認証は既定で無効」と明記しています。有効化するには、クラスタ起動前に環境変数を設定する必要があります。

RAY_AUTH_MODE=token

つまり2.52.0以降に更新しただけでは、認証なしのまま動き続けます。今回のブラウザ経由の攻撃は塞がりますが、ネットワーク的に到達できる相手からのジョブ投入は依然として素通りです。さらに公式ドキュメントは、トークンがHTTPヘッダで送られるため http 接続では平文で流れること、暗号化なしでRayクラスタをインターネットに公開してはならないことも警告しています。

脆弱性管理台帳は「バージョンが上がったか」で完了判定します。設定変更を伴う対処は、台帳上どれも同じ「対応済み」に見えてしまう点に注意してください。

修正版の公開からKEV追加まで約9か月

時系列を並べると、この脆弱性が「新しく出たもの」ではないことがわかります。

修正版が出てから約9か月、その間にRayは複数回のマイナーリリースを重ねています。にもかかわらず古いバージョンが残り、攻撃者に見つかったということです。pipで入るコンポーネントは、明示的に更新の仕組みを作らないと止まったまま動き続けます。

自社に該当するかをどう確認するか

Rayは資産管理ツールの「インストール済みソフトウェア一覧」には出てきません。OSのアプリケーションとしてではなく、Pythonパッケージとして入るためです。確認は次の順で行うのが現実的です。

• パッケージを直接見る：対象環境で pip list / pip show ray（あるいは uv pip list）を実行し、ray のバージョンが2.52.0未満でないか確認する
• ポートで探す：ダッシュボードの既定ポートは 8265。GPUサーバや開発端末で netstat / ss により8265番のリッスンを確認する。localhost束縛でも今回の攻撃は成立するので「外部に開いていないから対象外」とはしない
• プロセスで探す：ray start / raylet / gcs_server といったプロセス名で当たる
• 間接的な導入経路を確認する：vLLMでマルチノード推論を組んでいないか、Databricks Runtime ML 15.0以降のクラスタを使っていないか、Gemini Enterprise Agent Platform（旧Vertex AI）のRayクラスタを立てていないかを、AI開発チーム・データ分析チームに直接確認する

あわせて、Rayを触る担当者の端末で使っているブラウザも確認対象です。今回はFirefoxとSafariが影響し、Chromeは（偶然ながら）影響を受けません。ただしこれは対策ではなく事実の整理として押さえるにとどめ、ブラウザ選択を防御策にはしないでください。

現場目線の所感

この種のネタで毎回突き当たるのは、「そのサーバが社内のどこにあるのか情シスが知らない」という一点です。事業部門やデータ分析チームがPoCとして立てたGPUサーバが、いつの間にか業務で使われ続けている。調達を通っていないので台帳にも載らない。今回のRayはまさにその典型で、しかも狙われるのが担当者の手元の端末となると、ネットワーク機器の設定でまとめて塞ぐという手も打てません。

正直なところ、限られた人員でこれを網羅的に潰しにいくのは現実的ではありません。だからこそ、「AI関連の基盤を立てたら情シスに一報を入れる」という運用の合意を先に作るほうが、結果的に効きます。今回のようにKEV入りして期限が3日という短さで示されると、所在が分かっていない組織は初動の照会だけで期限を使い切ります。棚卸しは平時にしかできません。

また、CVE-2023-48022がDisputedのまま残っていることも現場を悩ませます。スキャナが検出しても「ベンダーが仕様だと言っている」で対応が止まりやすい。ベンダーの見解ではなく自社の資産の重要度で判断する、という原則に立ち戻る必要があります。

情シスはどうすべきか

打ち手は次の3つに整理できます。

1. Ray 2.52.0以降へ更新する（現在の最新は2.57.0）。ブラウザ経由の攻撃経路はここで塞がります
2. 更新後に RAY_AUTH_MODE=token でトークン認証を有効化する。更新だけでは認証なしのままです
3. 所在の把握を仕組みにする。AI基盤・分析基盤の立ち上げを情シスに通す運用と、外部公開面の継続的な把握

より広い対策の型については、自前でチェックリストを作るより公的機関の指針に沿うのが確実です。IPAの中小企業の情報セキュリティ対策ガイドラインは資産の把握と管理体制の作り方から解説しており、今回のような「台帳に載らない資産」の議論にも使えます。悪用確認済み脆弱性への初動を組織として決めておきたい場合は、IPAのセキュリティインシデント対応 机上演習教材が実践的です。

そして地味ですが効くのが、開発者・分析担当者への啓発です。今回の攻撃は「怪しいサイトを開かない」「業務端末で不用意な広告を踏まない」という基本が最後の壁になります。エンドユーザ向けにはIPAの対策のしおりが配布しやすい形にまとまっています。

まとめ

1. Ray 2.52.0未満のCVE-2025-62593が実攻撃で悪用され、2026年8月17日にKEV入りした。狙われるのは公開サーバではなくRayを動かす開発者・分析担当者の端末で、localhost束縛でも防げない
2. Rayは「制御されたネットワーク内での利用が前提」という設計方針で認証を持たなかった。2.52.0で追加されたトークン認証は既定で無効のため、更新だけでは認証なしのまま動き続ける
3. Rayはpipで入り資産台帳に載らない。vLLMのマルチノード推論やDatabricks Runtime ML 15.0以降など間接的に入っている経路も含めて、pip list・ポート8265・プロセス名で棚卸しする

関連記事：SGLangに未修正のRCE脆弱性、社内LLM基盤に警戒／NVIDIA Dynamoに15件脆弱性。社内LLM基盤の確認急げ／WordPress・Langflowの脆弱性悪用、CISAが警告／MCPサーバ91.8%が認証なし｜研究解説／EASMとは？外部攻撃対象領域管理の仕組みを解説

出典

• GitHub Security Advisory GHSA-q279-jhrf-cc6v（Ray公式アドバイザリ、2025年11月26日）
• CISA Known Exploited Vulnerabilities Catalog（2026年8月17日版）
• NVD – CVE-2025-62593
• NVD – CVE-2023-48022（Disputed）
• Ray公式ドキュメント – Authentication（トークン認証は既定で無効）
• Ray公式ドキュメント – ray start CLI（–dashboard-host / –dashboard-port の既定値）
• vLLM公式ドキュメント – Parallelism and Scaling（マルチノードの既定ランタイムはRay）
• Databricks公式ドキュメント – Create and connect to Ray clusters（DBR ML 15.0以降はRayをプリインストール）
• Google Cloud公式ドキュメント – Ray on Agent Platform（旧 Ray on Vertex AI）
• PyPI – ray（リリース日）