公開2026.08.24更新2026.09.27 脆弱性・インシデント

ShadowRay 2.0とは？Rayクラスタを狙う自己増殖ボットネットと露出面の閉じ方

社内のどこかで誰かが立てたRayクラスタが、気づかないうちに他社を攻撃する踏み台になっている。ShadowRay 2.0として報告された一連の攻撃は、そういう筋書きです。Rayのダッシュボードがインターネットから見えていれば、認証を通らずにジョブを投げ込めてしまい、投げ込まれたものはそのままクラスタ上のコードとして走る。奪われたクラスタはGPUを暗号資産の採掘に回され、次の獲物を探す散布装置にもされます。本記事では、悪用される二つのCVEの関係、攻撃が広がる順序、社内に散在するクラスタの探し方、版を上げるだけでは閉じない露出面の塞ぎ方を実装者の手順として並べていく。Ray自体の仕組みと採用判断はRayとは？分散処理フレームワークの仕組みと採用判断へ譲り、ここでは攻撃側から見た姿に絞ります。

まとめ｜ShadowRay 2.0への対応で先に決める三つのこと

結論から書きます。最初にやることは版上げではなく棚卸しです。社内でRayが動いている場所を全部並べ、ダッシュボードのポートが社外から到達できるものを特定してください。入口はここ一点で、閉じていれば残りは落ち着いて進められる。

二つ目は、2.52.0以降へ上げてもトークン認証は既定で無効という点です。版を上げただけでは、ジョブ投入の口は誰でも叩ける状態のまま残ります。環境変数で明示的に有効化するところまでを一組の作業として扱ってください。

三つ目は、侵害されている前提で痕跡を見に行くかどうかの判断です。露出した期間が数日でもあったなら、cronの登録、見慣れないカーネル風のプロセス名、説明のつかないGPU使用率の三点は確認しておきたい。露出の事実がなければ省いて構いません。

ShadowRay 2.0とは何か｜Rayクラスタを乗っ取る自己増殖型の攻撃キャンペーン

ShadowRay 2.0は、Oligo Securityが2025年11月初旬に確認したと報告する攻撃キャンペーンの呼称です。対象は分散処理フレームワークRayのクラスタで、狙いはGPUを含む計算資源そのもの。脆弱性の名前ではなく攻撃活動の名前だ、という点をまず押さえておきたい。

攻撃の成り立ち｜Jobs APIが認証なしでコード実行を受け付ける設計

Rayはクラスタへ処理を投げるための口を持っています。ジョブ投入のAPIがそれで、ここへ実行内容を渡すと、クラスタが受け取って走らせる。分散処理の道具として当然の機能です。

問題は、この口に既定で認証がないことでした。ダッシュボードのポートへ到達できる相手なら誰でもジョブを投げられる。認証を破る工程が丸ごと不要なコード実行の入口が、初期状態で開いていることになります。

Rayの公式文書はこの前提を隠しておらず、分離はクラスタの外側で担保するものだと明記しています。守るのは利用者側の責任範囲だ、という立て付けです。

2.0で変わった点｜奪ったクラスタから次を襲う自己増殖の仕組み

初報は2024年3月で、露出したクラスタに採掘器を仕込むという単純な形でした。2025年11月の第二波が別物なのは、奪ったクラスタ自体を次の攻撃元として使う点にあります。

侵入したクラスタから、世界中のRayダッシュボードへ向けて攻撃コードが撒かれる。感染したクラスタが増えるほど散布元も増えるため、広がり方はワームに近い。運営側の動きも速く、配布元のアカウントが削除されるたびに別のサービスへ移し、2時間ほどで再開していたと報告されています。

収益化の手口も一つではありません。CPU向けの採掘器に加え、NVIDIA A100のようなGPUを積んだノードには専用の採掘器、さらにDDoSの道具まで置かれていました。

露出台数｜インターネットに面したダッシュボードが20万台を超える

報告によれば、インターネットへ露出したRayサーバは2025年11月時点で20万台を超えており、2024年のおよそ10倍にあたります。AI基盤の普及に比例して、無防備な口の数も増えた形です。

これは標的型の話ではありません。攻撃側は開いている口を機械的に探すため、自社が小さいから狙われないという理屈は働かない。

二つのCVEの関係｜修正で閉じる欠陥と設計として残る到達経路の違い

二つのCVE番号は近い場所で語られるため、どちらに対応すべきかが見えにくい。役割が違うので分けて整理します。

CVE-2023-48022｜ベンダーが係争中とする無認証実行の側面

ShadowRay 2.0が実際に踏んでいるのはこちらです。CVSSは9.8で、内容はジョブ投入APIを通じた無認証のリモートコード実行。NVD上ではDISPUTED、つまり係争中の表示が付いています。

ベンダーであるAnyscaleの見解は、Rayは厳格に統制された網の外での利用を想定しておらず当該報告は該当しない、というもの。その環境内であれば2.52.0以降はトークン認証を選べる、と付記されています。

ここが対応設計の分かれ目になる。係争中で仕様寄りに扱われている以上、待っていても自動で塞がる種類のものではありません。CVE番号やCVSSの読み方そのものはCVE（共通脆弱性識別子）とは？仕組みとCVSS・CWE・NVDとの違いで整理しているので、社内で説明する際はそちらを土台にしてください。

CVE-2025-62593｜ブラウザ経由のDNSリバインディングで届く経路

もう一方は2025年11月26日に公開された別の欠陥で、CVSSは9.4。ブラウザ由来の攻撃に対する制御が不十分な点に起因し、DNSリバインディングとUser-Agentヘッダの改変を組み合わせることでリモートコード実行に至ります。

効き方が厄介です。Rayを動かしている開発者が悪意のあるサイトを踏むか、悪意のある広告を表示しただけで成立し得る。手元でしか動かしていないクラスタにも到達経路ができます。

こちらはPythonパッケージの2.52.0で修正されました。BitSightが2026年3月に出した報告では、RondoDoxというDDoSボットネットの運営者が公開の2日前からこの欠陥を使っていたとされています。

KEV登録と是正期限｜2026年8月に対応が求められた経緯を整理する

CISAは2026年8月17日、CVE-2025-62593を実際に悪用されている脆弱性のカタログへ追加しました。米連邦政府機関に対する是正期限は2026年8月20日と、極めて短い設定です。

民間企業に直接の法的拘束力はありません。ただしカタログへの登録は現に悪用が確認されている公的な裏づけなので、社内の優先度を上げる根拠には十分です。

項目	CVE-2023-48022	CVE-2025-62593
CVSS	9.8	9.4
入口	ジョブ投入API	開発者のブラウザ
状態	係争中・仕様扱い	2.52.0で修正
閉じ方	網の分離と認証	版上げ
本キャンペーン	これを悪用	別経路として並存

攻撃チェーンを実装の粒度で追う｜どこで止められた侵入だったのか

報告されている手口を段階に分けて見ていきます。各段階でどこに痕跡が残るかを併せて押さえると、後の確認作業がそのまま設計できる。

初期侵入｜ジョブ投入APIへのPOSTがそのままコード実行になる

攻撃側はまず、露出しているダッシュボードを機械的に探します。外部で応答を受け取る仕組みへ向けた攻撃コードを撒き、返ってきた通信で反応したホストを絞り込む手口でした。

反応があれば、あとはジョブを投げるだけです。認証がない以上、権限昇格も認証情報の窃取も要りません。ここが最大の関門で、ポートが閉じていれば以降の段階は発生しない。

横展開｜スケジューリング指定を使い全ノードへ配る手口の詳しい中身

Rayには、どのノードで処理を走らせるかを指定する仕組みがあります。攻撃側はこれを逆手に取り、クラスタ内で生存している全ノードへマルウェアを配って走らせていました。

分散処理の機能をそのまま配布経路に使うため、通信は正規のクラスタ内通信と見分けがつきません。ヘッドノードだけ確認して安心できないのはこのためです。

常駐と隠蔽｜15分周期のcronとカーネル風のプロセス名の偽装

常駐の手段はcronでした。15分ごとに外部から取得したスクリプトを走らせる登録が入るため、プロセスを落としても戻ってきます。

隠れ方も具体的です。バイナリ名をカーネルの作業スレッドや名前解決の常駐サービスらしき名前へ書き換える。さらにCPU使用率を6割程度に抑え、負荷監視の閾値に触れないようにしていました。GPUの使用状況はRayの監視画面から隠されていたとも報告されています。

増殖｜奪ったクラスタが世界中のダッシュボードへ攻撃コードを撒く

最後の段階が自己増殖です。侵害されたクラスタは、他のRayダッシュボードへ攻撃コードを撒く役割を負わされる。自社の計算資源が他社への攻撃元になるため、被害は自社の損失だけで終わりません。

段階	使われる仕組み	残る痕跡	止める打ち手
初期侵入	ジョブ投入API	ジョブ履歴	ポートを閉じる
横展開	ノード指定の実行	全ノードの新規プロセス	クラスタの分離
常駐	15分周期のcron	cron登録と取得通信	変更検知
隠蔽	プロセス名の偽装	名前と実体の不一致	実行監視
増殖	外向きの散布	大量の外向き通信	外向き通信の制限

社内に散在するRayクラスタを棚卸しする｜探す順序と見つからない理由

ここからが実務です。数え上げないまま対策を決めると、抜けた一台が入口になります。

探す順序｜クラウドの公開設定から開発者の手元まで四か所を順に見る

一つ目はクラウドの通信許可設定。セキュリティグループやファイアウォールの規則を、8265番を含む範囲で全リージョン分たどります。検証用に全開放したまま残った規則が、ここでよく出てくる。

二つ目はKubernetes上の公開設定。外部負荷分散やノードのポートを直接使う設定が対象です。KubeRayで立てた場合は、ダッシュボード用の口が意図せず外へ出ていないかを見ます。

三つ目はノートブック環境。マネージドのノートブックやGPUインスタンス上で起動したクラスタは、資産の台帳に載らないまま動き続けがちです。四つ目が開発者の端末で、後述のブラウザ経由の経路と直結します。外部から見える資産を継続して把握する枠組みは脆弱性対応の自動化｜ASM・BAS・ASVの使い分けと限界で扱っているので、恒久的な仕組みを作るならそちらも見てください。

誰も把握していないクラスタが生まれる｜起動時の既定値という原因

棚卸しで漏れるクラスタには共通の生まれ方があります。検証のために手軽に立て、そのまま忘れられるという経路です。

起動時の指定も効いてきます。待ち受けアドレスを全インターフェースに広げる指定でヘッドノードを立てると、その環境の外から到達できる状態になる。手元で試すつもりの指定が、クラウド上ではそのまま公開設定になります。

この構造は、部門が独自に導入したツールが把握されないまま増える話と同じ形をしています。背景の整理はシャドーITとは何か？非公認のITツールやサービスの定義にまとめました。Rayの場合は、そこに計算資源とコード実行が乗る分だけ影響が重い。

棚卸しの確認項目｜ポートと待ち受けアドレスを実機で突き合わせる

候補が挙がったら、実機で待ち受け状況を確認します。設定ファイルの記述ではなく、実際に開いている口を見てください。

ss -lntp | grep -E '8265|6379|10001'

待ち受けアドレスが全インターフェースなら、その時点で要注意です。次に社外の回線から到達できるかを実際に確かめます。

curl -s -m 5 http://対象ホスト:8265/api/version

応答が返るなら、そのクラスタは攻撃者からも同じように見えている。Anyscaleは公開ポートの確認ツールを出しているので、台数が多いときは併用してください。

露出面を閉じる手順｜版を上げるだけでは認証が有効にならない前提

対応の順序を四段階で示します。上ほど効きが強く、下へ行くほど補助的です。

まず外から切る｜ダッシュボードのポートを公開網から外す作業手順

最初に手を付けるのは通信経路です。8265番を含むRayの口を、インターネットから到達できない位置へ移します。踏み台やVPN経由でのみ届く形にするか、待ち受けをループバックへ絞る。

この作業は版上げより先に置いてください。版上げには停止と再起動が要りますが、通信規則の変更は稼働中でも即座に効きます。到達できる相手を絞る考え方の整理はゼロトラストネットワークの7つの要件｜NIST SP 800-207の7原則を参照してください。

トークン認証を明示的に有効化する｜既定では無効のまま動く注意点

2.52.0でトークン認証が入り、ダッシュボードからコマンドライン、APIクライアント、内部サービスまでが対象になりました。ただし公式文書には、2.52.0では認証が既定で無効だと書かれている。

つまり版を上げただけでは入口は開いたままです。環境変数で明示的に有効化してからクラスタを起動してください。

export RAY_AUTH_MODE=token
ray start --head --dashboard-host 127.0.0.1

トークンは環境変数、パス指定、既定の保存場所の順に探索されます。有効化した後は、既存の運用スクリプトやジョブ投入の経路がトークンを渡せているかを一通り確認してください。

ブラウザ経由の到達を塞ぐ｜開発機で動かすクラスタの扱いを決める

CVE-2025-62593への対応がここに入ります。2.52.0以降へ上げるのが本筋で、上げられない事情があるなら、開発機でクラスタを起動したまま日常のブラウジングを行う運用を見直してください。

手元で立てたクラスタは外から見えないから安全、という前提がこの欠陥で崩れます。使い終わったら落とす、作業用のブラウザ環境を分ける、といった運用側の線引きを決めておくほうが確実です。

それでも残る前提｜信頼された網の中で動かす設計は変わっていない

ここまでやっても、Rayが信頼された網で信頼されたコードを動かす前提の道具である点は変わりません。公式の立場は、分離をクラスタの外側で担保することにあります。

したがって、クラスタを置く網の区切り方が最後まで効きます。学習用と推論用、本番と検証を別網に置く分割を設計へ入れておく。露出面を一度きりでなく継続して見る枠組みはCTEMとは？脆弱性管理との違い・5つの段階と導入判断で扱っています。

侵害の有無を確かめる｜クラスタとノードに残る痕跡の具体的な見つけ方

露出していた期間があるなら、閉じた後に痕跡を見に行きます。順序を決めて短時間で回すのが現実的です。

痕跡の確認項目｜cronとプロセス名とGPU使用率を順番に当たる

最初にcronを見ます。ヘッドノードだけでなく、全ワーカーノードが対象です。

crontab -l ; ls -la /etc/cron.d

15分周期で外部からスクリプトを取得する登録があれば、その時点でほぼ確定と考えてよい。次にプロセス一覧で、カーネルの作業スレッドや名前解決の常駐サービスらしき名前がユーザ領域から起動していないかを見ます。名前と起動元の不一致が手がかりです。

三つ目がGPUの使用率で、ジョブを止めても落ちないなら疑ってください。名前解決の設定ファイルとパケットフィルタに見覚えのない項目が足されていないかも確認します。採掘マルウェア一般の検出と駆除の手順は暗号通貨マイニングマルウェアの検出方法｜侵入経路と駆除手順にまとめてあるので、実作業はそちらの手順に沿って進められます。

見つかったときの手順｜隔離して保全してから作り直すという判断順序

侵害が確認できたら、まず網から切り離します。電源を落とすのではなく通信だけを止める。落とすとメモリ上の情報が消え、後から経路をたどれなくなります。

次に保全です。cronの登録内容、プロセス一覧、外向き通信のログ、ジョブの投入履歴を取得しておく。他のクラスタも同じ経路で侵害されていないかの判断材料になります。

復旧は駆除ではなく作り直しを勧めます。常駐の手段が複数仕込まれている前提では、一つずつ消して残りを見落とす危険が大きい。ノード側の検知と対処を仕組みとして持つ話はEDRとは？EPP・XDRとの違いと検知の仕組み・導入判断で扱っています。

あわせて確認したいのが持ち出しの有無です。報告では環境変数からデータベースの認証情報が抜かれ、共有ストレージ上の独自コードや学習データも参照できる状態だった。クラスタから見えていた資産を洗い出し、認証情報は差し替えてください。

Rayを使い続けるかどうかの判断｜採用してよい条件と構成を変える場面

ここは言い切ります。ShadowRay 2.0を理由にRayをやめる必要はありません。ただし、条件を満たさないまま使い続けるのは勧めない。

使い続けてよい条件｜閉じた網とトークン認証と監視の三つがそろう場合

条件は三つです。一つ目、クラスタが閉じた網の中にあり、ダッシュボードとジョブ投入の口がインターネットから到達できないこと。二つ目、2.52.0以降でトークン認証を明示的に有効化していること。三つ目、ノード上で起動するプロセスと外向き通信を継続して見ていること。

この三つがそろっているなら、Rayは引き続き使えます。三つ目だけが欠けた状態は許容できる場合がある。侵入経路が塞がっていれば、監視は発見の遅れを縮める役割にとどまるためです。

構成を変えるべき場面｜開発者の手元で立てたクラスタをそのまま残さない

見送るべきなのは、開発者が各自の判断でクラスタを立てられる運用です。誰がいつ何を立てたかを追えない状態では棚卸しが常に後追いになり、一台の取りこぼしが全体の入口になります。

この場合はRayをやめるのではなく、立て方を集約してください。起動を基盤側の手順に寄せ、通信規則と認証設定を組み込んだ形でしか作れないようにする。個人の端末で長時間動かす使い方も残さない判断が要ります。

外部の手を借りる境界｜診断と設計のどこから委託すると早いのか

自社で進められるのは、棚卸しと通信規則の変更、そして版上げまでです。ここは手順が明確なので、内製で十分に回ります。

判断が要るのは、閉じた後の構成をどう設計するか、侵害の有無をどこまで言い切れるかです。網の区切り方や、痕跡が出なかったことをもって安全と判断してよいかは経験の差が出る。露出面の確認と侵害調査を外へ出すなら脆弱性診断・セキュリティ診断のような形で、対象範囲と報告の粒度を先に決めて依頼するのが早い。

逆に、棚卸しが終わらないうちに診断を頼むと、対象リストの作成から始まって費用と時間がかさみます。自社で数え上げてから外へ渡すのが無駄がない。

よくある質問

ShadowRay 2.0はCVE-2025-62593の攻撃キャンペーンですか？

厳密には違います。ShadowRay 2.0が悪用しているのはCVE-2023-48022、つまりジョブ投入APIが無認証でコード実行を受け付ける側です。CVE-2025-62593はブラウザ経由のDNSリバインディングで到達する別の欠陥で、2026年8月17日にCISAのカタログへ追加されました。並べて語られるのは、どちらもRayクラスタでの任意コード実行に至るため。対応は前者が網の分離と認証、後者が2.52.0以降への版上げになります。

Rayを2.52.0へ上げれば対応は完了しますか？

完了しません。2.52.0はCVE-2025-62593の修正版であり、同時にトークン認証が入った版でもありますが、公式文書によれば認証は既定で無効です。環境変数RAY_AUTH_MODEにtokenを設定して有効化するまで、ジョブ投入の口は認証なしのまま動く。版上げと認証の有効化と通信規則の見直しを一組の作業として扱ってください。将来の既定有効化は計画段階で、2026年8月時点では利用者側の設定が要ります。

クラウドの閉じた網にあるクラスタも危険ですか？

インターネットから直接到達できないなら、初期侵入は成立しません。ただしCVE-2025-62593はクラスタへ接続できる開発者のブラウザを経由するため、閉じた網でも到達経路が残ります。開発端末から社内網のクラスタへ届く構成では、版上げの優先度を下げないでください。社内の別端末が侵害されたときの横展開も考えると、閉じた網でもトークン認証は有効化する価値があります。

侵害されたかどうかは何を見れば判断できますか？

優先順に三つあります。第一に全ノードのcron登録で、15分周期で外部からスクリプトを取得する記述が典型です。第二にプロセス名と起動元の不一致で、カーネルの作業スレッドや名前解決サービスを装った名前が使われていました。第三はジョブを止めた状態でのGPU使用率。加えて外向きの通信量も見ます。一つでも該当すれば、網から切り離してから調査を進めてください。