CISA、Rayの脆弱性を「悪用が確認済み」に追加 - 狙われるのは開発者の手元のマシン

米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）が2026年8月17日、脆弱性1件をKnown Exploited Vulnerabilities（KEV）カタログに追加した¹。追加されたのは CVE-2025-62593「Ray-Project Ray Code Injection Vulnerability」——分散処理フレームワークRayのコードインジェクションの脆弱性である¹。

KEVは「実際に悪用されていることが確認された脆弱性」の一覧で、CISAは今回の追加についても、活発な悪用の証拠に基づくものだと明記している¹。脆弱性そのものは新しくない。開発元のGitHub Security Advisoryは2025年11月26日に公開され、Ray 2.52.0 ですでに修正されている³。今回変わったのは、それが現実に使われているという判定が付いたことだ。

「開発ツールとして使っている開発者」が対象

KEVカタログのエントリは、この脆弱性をこう説明している——Rayはリモートコード実行を許しうるコードインジェクションの脆弱性を含んでおり、Rayを開発ツールとして使っている開発者が、FirefoxとSafari経由で悪用されうる形でこの脆弱性にさらされる可能性がある²。

サーバ側の話ではない、というところが目を引く。開発元のアドバイザリのタイトルも「ブラウザ（SafariとFirefox）経由でDNSリバインディング攻撃により悪用可能な、Ray開発者に対する重大なRCE脆弱性」だ³。

仕組みは、防御が薄い場所と、ブラウザの古典的な弱点の組み合わせになっている。アドバイザリによれば、/api/jobs や /api/job_agent/jobs/ といった重要なエンドポイントに認証を実装しないというRay開発チームの長年の決定が、再び、Rayに対して任意のコードを実行できる深刻な脆弱性につながった³。ブラウザからの攻撃に対する防御は用意されていたが、それは User-Agent ヘッダが “Mozilla” という文字列で始まるかどうかを見るだけのもので、fetch仕様では User-Agent を変更できるため不十分だった³。

そこにDNSリバインディング攻撃を組み合わせると、Rayを動かしている開発者が意図せず悪意あるWebサイトを訪れた場合、あるいは悪意ある広告（マルバタイジング）を配信された場合に、悪用が成立する³。アドバイザリの「影響」の節は端的だ——フィッシング攻撃の被害に遭ったり悪意ある広告を配信されたりすると、開発者のマシン上で任意のシェルコードが実行されうる³。

もうひとつ、範囲が広がる経路も書かれている。この攻撃は、ブラウザを confused deputy（混乱した代理人）の中継役として利用することで、社内のプライベートネットワーク内で動いているネットワーク的に隣接したRayインスタンスへの攻撃にも転用できる³。手元のブラウザが、内側にあるはずのRayへの入口になるという構図だ。

CVSS v4のスコアは9.4で、深刻度はCritical と評価されている³。影響を受けるのはPythonパッケージ ray のバージョン 2.52.0 未満で、修正済みバージョンは 2.52.0 である³。

期限は8月20日、ただし対象は連邦機関

対応の期限は、アラートではなくKEVカタログのエントリ側に載っている。CVE-2025-62593 のエントリは、追加日が2026年8月17日、dueDate が 2026年8月20日 である²。

義務の範囲も限定されている。アラートは、Binding Operational Directive（BOD）26-04「Prioritizing Security Updates Based on Risk」が連邦民間行政機関（FCEB）に対する脆弱性管理の要件を定めるものだと説明する¹。BOD 26-04はKEVカタログの重要性を補強し、悪用後に資産の完全な制御を与えるような、公開露出した資産上のKEV掲載CVEについて迅速な修正を優先するよう連邦機関に求める一方、より低リスクの脆弱性については対応を後回しにすることを認める¹。

そして明示的に、BOD 26-04が適用されるのはFCEBのみであり、CISAはすべての組織に対してリスクベースの脆弱性管理を採用しKEV掲載の脆弱性の修正を優先することを「奨励する」と書いている¹。日本の企業に法的な期限が生じるという話ではない。

KEVエントリの「要求される対応」には、ベンダの指示に従って緩和策を適用し、BOD 26-04のガイダンスと「Forensics Triage Requirements」への準拠を確保すること、クラウドサービスについては該当するガイダンスに従うか緩和策がない場合は当該製品の利用を停止すること、各利害関係者が資産のインターネット露出を評価する責任を負うことが書かれている²。ランサムウェアキャンペーンでの使用は “Unknown” とされている²。

手元で確認すべきこと

Rayは分散学習・分散推論のジョブ実行に使われるフレームワークで、本番のクラスタだけでなく、開発者のノートPC上でローカルに立ち上がっていることが多い。今回の脆弱性がそこを突く形なので、点検の場所ははっきりしている。手元とCI環境のRayのバージョンが 2.52.0 以上かどうかだ。

修正は 2.52.0 以上への更新で、このバージョンでは、この脆弱性に対してさらに堅牢化できる既定で無効のトークン認証機能もついに追加された、とアドバイザリは書いている³。認証を有効にするかどうかは別の判断になるが、「重要なエンドポイントに認証がない」という前提そのものが変えられるようになった点は押さえておきたい。

ブラウザ側の対策に期待するのは早いようだ。アドバイザリは、いくつかのブラウザがこの攻撃を19年間知りながら最近になってDNSリバインディングへの堅牢化を始めた（Chrome の Local Network Access）としつつ、これらの変更は保護になる「かもしれない」が、以前の取り組み “private network access” はロールバックされた、と書いている³。そのうえで、多層防御の戦略として更新が強く推奨される、と結論している³。

なお、発見のクレジットは、fetchのバイパスを理論化したOligoの@avilumと、DNSリバインディングの段階・完全なPoC・開示を担ったSocket在籍時の@JLLeitschuhに置かれている³。

「AIの実行環境」がそのまま攻撃面になる

この一件は、単体のCVEとして片づけるより、この夏に続いている流れの中で読むほうが手がかりが多い。

WizがSnowflakeのGitHub Actionsで示した事例は、誰でも起動できるCIワークフローが信頼できない入力をシェルに渡していたという話だった。今回は、ローカルの開発環境が認証なしのAPIを開いていて、そこに外部のWebページから届いてしまう。共通しているのは、モデルやジョブを動かすための便利さがそのまま攻撃面になっている点だ。

翌8月18日には、OpenAIが研究環境のワークロード隔離とネットワーク隔離を要件として追加したことを公表している。そこで書かれていた設計思想——単一のワークロードや補助サービスが侵害されただけでは、それ自体ではインターネットや他の内部ネットワークへの不正アクセスに至らないようにする——は、まさに今回の「ブラウザを踏み台に社内のRayを叩ける」という経路を潰す考え方にあたる。規模はまったく違うが、点検すべき場所の性質は同じだと考えられる。

社内でAIのワークロードを回している組織にとっては、MicrosoftがZero Trust WorkshopにDevSecOpsの柱を新設したときに対象になった領域が、そのまま今回の点検範囲と重なる。開発機・CI・実験用クラスタは、本番より管理が緩くなりやすく、それでいてモデルやデータに届く距離は近い。KEVへの追加は、その距離が実際に使われていることの通知として読める。