AI導入のセキュリティを議論するとき、話題はたいてい「入力した社内データが学習に使われないか」に向かう。今回カタログに載ったのは、別の場所である。AIを作っている側の端末と、条件がそろえばそこから手が届く社内ネットワークだった。
米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）は、2026年8月17日付で公開したKnown Exploited Vulnerabilities Catalog（悪用が確認された脆弱性のカタログ、以下KEV）のバージョン2026.08.17に、Ray-Project の Ray に存在するコードインジェクションの脆弱性 CVE-2025-62593 を追加した。是正期限は2026年8月20日である。同カタログの登録件数はこの版で1,666件になっている。
Ray は、機械学習の学習・推論・データ処理を複数のマシンに分散させるためのオープンソースのフレームワークである。AIの実験や学習を回す側が使う道具であって、業務システムの利用者が直接触るものではない。だからこそ、今回の追加は読み方を間違えやすい。
この記事を読むべき人
- AI・機械学習の開発やPoCを外部の開発会社に委託している会社
- 社内のエンジニアがAIの検証環境を自前で立てている会社
- 「AIのセキュリティ」を、入力データの取り扱いの問題としてだけ捉えている経営者
- 委託先の開発環境について、契約書に何も書いていない会社
- OSSを組み合わせた開発を発注していて、脆弱性の管理責任が誰にあるか決めていない会社
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
KEVの記載を読む
CISAがカタログに記した説明は次の通りである。Ray-Project の Ray にはコードインジェクションの脆弱性が存在し、リモートでのコード実行を許す可能性がある。Rayを開発ツールとして使用している開発者は、FirefoxおよびSafariを通じて悪用可能なこの脆弱性にさらされる可能性がある。
対応として求められているのは、ベンダーの指示どおりに緩和策を当てたうえで、CISAのBOD 26-04「Prioritizing Security Updates Based on Risk」と「Forensics Triage Requirements」に沿って処理することである。クラウド上で使っている場合も同指令の該当箇所に従うこととされ、緩和策が用意されていないなら製品の利用そのものをやめるという選択肢まで書かれている。資産ごとにインターネットからどれだけ見えているかを見極める責任は、利用者の側にあるとも明記されている。
分類されている脆弱性の型はCWE-94（コード生成の制御不備）とCWE-352（クロスサイトリクエストフォージェリ）の2つである。ランサムウェアキャンペーンでの利用については「Unknown」と記載されており、ランサムウェアに使われていると確認されたわけではない。
なお、KEVの是正期限は米国の拘束的運用指令（BOD）の対象となる連邦民生行政機関（FCEB）へ向けたものであり、日本の民間企業がこの日付に法的に縛られるわけではない。日本企業にとっての意味は別のところにある。悪用が実際に確認されたと米国政府機関が判断した、という事実のほうである。
「Mozillaで始まるかどうか」で守っていた
技術的な中身は、開発を委託している側にも読む価値がある。なぜなら、ここに出てくるのは高度な攻撃手法ではなく、設計判断の話だからである。
Ray の開発チームが公開したセキュリティアドバイザリ GHSA-q279-jhrf-cc6v は2025年11月26日付で、深刻度は Critical と評価されている。影響を受けるのは pip パッケージの ray のバージョン 2.52.0 未満で、修正版は 2.52.0 である。
アドバイザリの説明はかなり率直である。/api/jobs や /api/job_agent/jobs/ といった重要なエンドポイントに認証を実装しないというRay開発チームの長年の判断が、再び深刻な脆弱性につながった、と書かれている。今回はブラウザ、それもFirefoxとSafariを経由した開発環境での話である、と続く。
では認証がないなら何で守っていたのか。ブラウザからのリクエストを弾く仕組みが入っており、その判定は「User-Agentヘッダーが Mozilla という文字列で始まるかどうか」だけだった。アドバイザリに引用されているコードには、この判定について「この経験則は非常に弱い（This heuristic is very weak）」というコメントが開発者自身の手で書かれている。
この防御が破れる理由は、前提が間違っていたからである。FirefoxとSafariでは、fetch APIからUser-Agentヘッダーを別の値に設定できる。アドバイザリは、これがfetchの仕様に沿った動作であると説明している。Chromeが影響を受けないのは、皮肉なことにChrome側のバグによってfetchの仕様から外れているためである、とも書かれている。守れていたブラウザがあったのは、設計が正しかったからではなかった。
悪用にはDNSリバインディング攻撃が必要になる。アドバイザリは、これが nccgroup/singularity のような現代的なツールで容易に実行できると述べている。成立する条件は、Rayを動かしている開発者が悪意あるWebサイトを不用意に訪問するか、悪意ある広告を表示させられることである。アドバイザリは後者を malvertising として明示している。攻撃対象となるポートは、Rayのダッシュボードが使う8265である。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
経営として押さえるべき一点
技術の詳細は委託先が理解していればよい。経営側が読み取るべきなのは、次の一点である。
AIの開発に使われる基盤ソフトウェアには、「認証をかけない」ことを前提に設計されているものがある。 ローカルで動かす開発ツールだから、社内ネットワークにあるから、という理由で認証を省く設計は珍しくない。アドバイザリは修正版の2.52.0について、この版で「ようやく（finally）」認証機能が追加されたと記しており、しかもその機能は既定では無効であるとしている。 更新しただけでは認証が有効にならない、という意味である。
そしてもう一つ。起点になるのは本番サーバではなく、開発者の手元である。 サーバの堅牢化やWAFの導入といった対策は、開発者のノートPCで動いているRayには効かない。AIのPoCを進めている会社が「まだ本番ではないから」とセキュリティの検討を後回しにしているとき、その「まだ本番ではない環境」が最初の入口になる。
ただし、影響がそこで止まるとは書かれていない。 アドバイザリの「Impact」の節には、この攻撃はブラウザを「混乱した代理人（confused deputy）」として中継させることで、社内の閉じたネットワークで動いている別のRayインスタンスへの攻撃にも利用できると記されている。開発端末が入口になり、そこから社内ネットワーク側のRayへ手が伸びる、という順序である。 「開発環境の話だから本番には関係ない」とは言い切れない。
深刻度についても補足しておく。アドバイザリはこの脆弱性をCriticalとし、CVSSの総合スコアを9.4と記載している。
8か月以上放置されていた期間をどう見るか
日付の並びにも意味がある。アドバイザリの公開は2025年11月26日、KEVへの追加は2026年8月17日。CVE番号も CVE-2025-62593 と2025年の採番である。修正版が出てから8か月以上が経過したあとで、悪用が確認された脆弱性として登録されたことになる。
修正が出た時点で更新できていれば影響はなかった、という単純な話にはしない。ここで問うべきは、自社および委託先が「8か月前に出たOSSの修正版に追従できているか」を確認する手段を持っているかである。本番システムのパッチ適用手順は決めている会社でも、開発環境や検証環境の更新を誰がいつやるかまで決めている会社は少ない。
参考までに、KEVの是正期限の設定そのものも2026年に入って変わっている。筆者が2026年8月17日版のカタログ全1,666件を集計したところ、2024年に追加された186件のうち175件、2025年に追加された245件のうち226件は、追加日から21日後が期限だった。ところが2026年に追加された182件では、3日後が74件、14日後が61件、21日後が44件と分散し、残る3件は2日後が2件、5日後が1件だった。2026年6月1日以降に追加された59件に限ると、3日後が48件、14日後が11件で、21日後はゼロである。今回のRayも3日後の設定である。
この分布は偶然ではない。 今回のRayの項目にも書かれているとおり、CISAは是正にあたってBOD 26-04「Prioritizing Security Updates Based on Risk」のガイダンスに従うことを求めている。同指令は、資産がインターネットから到達できるか、KEVに載っているか、悪用を自動化できるか、掌握の程度はどこまでか、という組み合わせで是正期限を定める枠組みを示している。期限が3日と14日に分かれているのは、この枠組みが働いた結果である。 指令の中身と、日本企業がこれを自社のパッチ運用へどう移し替えるかはCISA BOD 26-04を日本企業のパッチ運用へ翻訳するで詳しく扱っている。
上の集計で言えるのは、その枠組みがカタログの実データにも現れているということである。 一律に21日後としていた運用が2026年に入って分散し、6月1日以降は3日後か14日後のどちらかに収束している。
「3週間あれば足りる」という前提で組んだパッチ運用は、少なくとも米国側の要求水準とは合わなくなっている。 自社の運用が月次のメンテナンス枠に依存しているなら、悪用確認済みの案件だけを別扱いにする経路を用意しておきたい。
委託先に投げたい5つの質問
以下は、AI開発を委託している会社がベンダーへ確認するためにGXOが使っている質問である。CISAやRay開発チームが推奨しているものではない。
質問1：当社の案件でRayを使っていますか。使っている場合、バージョンは2.52.0以上ですか。 使っていない場合でも、この質問には意味がある。使用しているOSSとそのバージョンを即答できるかどうかが分かる。
質問2：開発環境と検証環境のOSSは、誰がいつ更新していますか。 本番環境の話にすり替わった場合は、もう一度開発環境について聞き直す。
質問3：開発者の端末で動いている開発用サービスは、どのポートで、どの範囲に公開されていますか。 「ローカルだから外からは見えない」という回答が返ってきたら、今回のDNSリバインディングの件を伝えて再考を依頼する。
質問4：使用しているOSSの脆弱性情報を、どの経路で受け取っていますか。 GitHubのセキュリティアドバイザリ、KEV、JVNなど、経路が具体的に挙がるかを見る。
質問5：当社の案件で使うOSSに緊急の脆弱性が出た場合、何日で対応してもらえますか。その費用は保守に含まれますか。 日数と費用負担が契約書のどこにも書かれていない案件は多い。書かれていない場合、実際に事故が起きたときの交渉は不利になる。
社内で今日できる棚卸し
委託先への確認と並行して、社内でもできることがある。特別なツールは要らない。
- AIやデータ分析の検証環境が、誰の端末・どのサーバで動いているかを一覧にする
- その環境が、いつ・誰の判断で立ち上がったかを確認する
- 立ち上げた本人が退職・異動していないかを確認する
- 今も使っているのか、使っていないのに動いたままなのかを確認する
- 使っていないものは止める
最後の項目が最も効く。 使われていない検証環境は、更新も監視もされないのに、止める判断だけが誰からも下されないまま動き続ける。8か月以上前に修正版が出ている脆弱性が今も残っているとしたら、真っ先に疑うべきはこの種の環境である。
よくある質問
Q. 当社ではRayを使っていない。関係あるか。 A. Ray そのものは関係ない。関係するのは、AIの開発環境が攻撃対象になり得るという点と、自社が使っているOSSを把握しているかという点である。使用しているOSSの一覧が出てこない場合は、そちらのほうが優先度の高い課題である。
Q. 開発は全部外注している。当社側で何かする必要があるか。 A. 外注していても、成果物と開発環境の管理責任の所在は契約で決まる。契約書に開発環境のセキュリティ要件が書かれていない場合、事故が起きたときに「決めていなかった」ことが争点になる。上記の5つの質問を投げて、回答を文書で残しておきたい。
Q. 是正期限の8月20日を過ぎたら危険度が上がるのか。 A. そうではない。この日付は米国の連邦民生行政機関（FCEB）に課された期限であり、脆弱性の危険度が日付で変わるわけではない。日本企業にとっては、悪用が確認されている以上、対応の優先度が高いという事実だけが意味を持つ。
Q. 開発環境の話なら、本番システムには影響しないのか。 A. そう言い切れない。アドバイザリは、ブラウザを中継させて社内ネットワーク上の別のRayインスタンスを攻撃できると記している。開発端末が入口になり、そこから社内側へ広がる経路が想定されている。
Q. Chromeを使っていれば安全か。 A. アドバイザリは、Chromeがfetchの仕様から外れているために影響を受けないと説明している。しかしこれはChromeの実装上の事情であり、将来も安全である保証にはならない。同アドバイザリは、いくつかのブラウザがDNSリバインディングへの防御を最近になって強化し始めたこと（Chrome Local Network Access）に触れつつ、以前の取り組みである "private network access" は撤回されたため、多層防御として更新を強く推奨するとしている。ブラウザの選択を対策の柱にするのは適切ではない。
Q. 社内にOSSの脆弱性を追える人がいない。 A. 全部を追うのは現実的ではない。まず「自社が使っているOSSの一覧」を作ることを優先したい。追う人がいなくても、一覧さえあれば、情報が出たときの当否判断は外部に相談できる。逆に一覧がない状態では、相談を受ける側も答えようがない。
Q. PoCの段階でもセキュリティにコストをかけるべきか。 A. 「PoCだから軽くてよい」とは決まらない。水準は段階ではなく、その環境が何につながっているかで決める。 見るべきは、本番データを読ませているか、本物の認証情報を置いているか、社内ネットワークから到達できるか、外部に公開されているか、の4点である。該当する項目があるなら、影響の大きさと到達のしやすさに応じて、本番相当まで含めた水準を個別に決めることになる。 どれにも当てはまらない閉じた環境であれば、水準を下げる判断もあり得る。なお、Rayの件についてアドバイザリが求めている直接の対策は2.52.0以上への更新である。判断の前提として、どの環境がどこに存在するかの記録は要る。今回の件で問題になるのは、その記録がないまま残り続けている環境である。
8月20日までにできること、その先にやること
期限が3日しかない告知に対して、3日でできることは限られている。だからこそ、何を今日やり、何を来月の計画に載せるかを分けておきたい。
今日から今週にかけては、範囲の特定が中心になる。委託先へ本稿の5つの質問を送り、社内では動いている検証環境を一覧にする。ここで「どのOSSがどこで動いているか分からない」という結論になる会社は少なくない。その場合、個別の脆弱性を追う前に全体を洗い出したほうが早い。GXOでは脆弱性診断で、この棚卸しと優先順位づけまでを受けている。
来月以降の計画に載せるのはこの2つである。ひとつは、開発工程そのものにセキュリティの確認を組み込むこと。DevSecOpsで扱っている領域にあたる。もうひとつは、生成AIやAI基盤を使うこと自体に伴うリスクを整理することで、こちらは生成AIセキュリティが対応する範囲である。対策の順序を先に決めたい場合は中小企業のセキュリティ優先順位を参照されたい。
委託先へ質問を送った結果、契約書に開発環境について何も書かれていないと判明することがある。 その場合は稼働前が交渉の好機であり、契約と体制を相談するから点検できる。AI導入そのものを進めるかどうかの段階ならAI導入前チェック、PoCから本番へ移す判断はPoC本番化診断で扱っている。
過去のKEV追加を扱った記事はMetabaseのSQLインジェクションとBI基盤とNVIDIA Dynamoの脆弱性とAI推論基盤にある。本稿の焦点は、標的が開発者の端末から始まり、社内ネットワークへ及び得るという経路そのものにある。
参照した情報
- CISA「Known Exploited Vulnerabilities Catalog」（カタログ版 2026.08.17、公開日時 2026年8月17日）: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- 同カタログのJSON（本稿の集計に使用）: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
- ray-project/ray セキュリティアドバイザリ GHSA-q279-jhrf-cc6v（2025年11月26日公開）: https://github.com/ray-project/ray/security/advisories/GHSA-q279-jhrf-cc6v
- NVD CVE-2025-62593: https://nvd.nist.gov/vuln/detail/CVE-2025-62593
CVE-2025-62593 の追加日（2026年8月17日）、是正期限（2026年8月20日）、脆弱性名、CISAによる説明文、要求される対応、CWE-94とCWE-352の分類、ランサムウェアキャンペーンでの利用が「Unknown」である旨、およびカタログの版と登録件数1,666件は、上記CISAのJSONを取得して確認した。
影響を受けるバージョンが ray（pip）2.52.0未満で修正版が2.52.0である旨、深刻度がCriticalでCVSSの総合スコアが9.4である旨、アドバイザリの公開日が2025年11月26日である旨、2.52.0で既定では無効の認証機能が追加された旨、ブラウザを「混乱した代理人」として中継し社内の閉じたネットワーク上の別のRayインスタンスを攻撃できる旨、認証を実装しないという開発チームの判断に関する記述、User-Agentが「Mozilla」で始まるかで判定していた旨とコード中の「この経験則は非常に弱い」というコメント、FirefoxとSafariのfetch APIでUser-Agentを変更できる旨、Chromeがバグによりfetchの仕様から外れているため影響を受けない旨、DNSリバインディング攻撃を要する旨、nccgroup/singularity への言及、malvertising への言及、および対象ポートが8265である旨は、上記のセキュリティアドバイザリを取得して確認した。
是正期限の日数別集計（2024年186件中175件が21日、2025年245件中226件が21日、2026年182件が3日74件・14日61件・21日44件・2日2件・5日1件、2026年6月1日以降の59件が3日48件・14日11件・21日0件）は、上記JSONの dateAdded と dueDate の差から筆者が算出したものである。 是正期限の決め方そのものは BOD 26-04 が定めており、その内容は上記のKEVカタログの requiredAction 欄から参照されている。本稿は集計値を示すにとどめ、今後の運用を予測するものではない。
本稿の「委託先に投げたい5つの質問」と「社内で今日できる棚卸し」は、CISAやRay開発チームが示した対応策ではない。 AI開発の発注側を支援してきた立場から、公表された事実をもとにGXOが導き出した確認項目である。なお、KEVの是正期限は米国の連邦民生行政機関（FCEB）に課される要求であり、日本の民間企業を法的に拘束するものではない。Rayという製品そのものの安全性を評価する意図も、本稿にはない。
