Ray 严重漏洞 CVE-2025-62593 被 CISA 列入 KEV：AI 基础设施的"信任网络"假设正在崩塌

2026 年 8 月 17 日，美国网络安全和基础设施安全局（CISA）将开源分布式计算框架 Ray 的一个严重漏洞 CVE-2025-62593 加入"已知被利用漏洞"（Known Exploited Vulnerabilities，KEV）目录，并给联邦民事行政部门（FCEB）机构下达了一个异常紧迫的修复期限——2026 年 8 月 20 日，也就是公告发出后的第三天。这个漏洞的 CVSS 4.0 评分高达 9.4 分，攻击者只需要诱导一名在本机跑着 Ray 的开发者访问一个恶意网页，就能在完全不需要用户交互、不需要窃取任何凭证的情况下，远程执行任意代码。更值得警惕的是，这不是一个"理论上可利用"的漏洞：安全研究机构 BitSight 的报告显示，RondoDox DDoS 僵尸网络团伙早在漏洞正式公开披露前两天就已经把它武器化，而名为 ShadowRay 2.0 的攻击活动则持续在把未修补的 Ray 集群变成自我复制的加密货币挖矿僵尸网络。对于每天在用 Ray 做分布式训练、超参数搜索、强化学习或者 Agent 编排的国内外开发者来说，这不是一条可以划过去的安全新闻，而是一个需要立刻停下来检查自己环境的紧急事项。

一、背景：Ray 是什么，为什么这次漏洞格外危险

Ray 是由 UC Berkeley RISELab 孵化、目前由 Anyscale 主导维护的开源分布式计算框架，是当前 AI/ML 领域最主流的分布式执行引擎之一。它的应用范围极广：从模型训练时的数据并行、超参数调优（Ray Tune），到强化学习训练（RLlib），再到近两年爆发式增长的 LLM 推理服务和 Agent 编排（vLLM、许多多智能体框架底层都依赖 Ray 做任务调度），几乎每一个中大型 AI 团队的基础设施里都能找到 Ray 的身影。

Ray 的设计哲学决定了它天生的风险敞口：它被设计成一个"面向可信网络的集群计算框架"（cluster compute framework for trusted networks），核心功能之一就是让集群里的节点能够远程执行代码——这本来就是分布式计算的题中之义。问题在于，过去几年 AI 基础设施的部署现实已经从"实验室里跑在防火墙后面的研究集群"迅速迁移到了"生产环境""云端多租户平台""开发者本地笔记本电脑"，而 Ray 对外暴露的管理接口，安全边界却没有跟上这个变化。这也是为什么 compliancehub.wiki 的分析把 Ray、Langflow、llama.cpp 归为同一类模式："为可信网络设计，却被部署在不可信网络上"——代码执行是它们的既定功能，而不是漏洞，功能和漏洞之间的边界完全取决于访问控制是否到位，而这些工具默认往往是没有认证或认证可选的。

二、技术细节解析

1. 漏洞成因：一个基于 User-Agent 的"安全检查"

CVE-2025-62593 的根本原因，用 Ray 维护团队自己的话说，是"长期决定不在关键端点实施任何身份验证"。具体来看，Ray Dashboard 暴露的 /api/jobs 和 /api/job_agent/jobs/ 等 HTTP 接口可以直接提交或触发在 Ray 集群上执行任意代码，而这些接口原本依赖的唯一防护，是检查请求头中的 User-Agent 字段是否以 Mozilla 开头——用这个粗糙的规则去判断"请求是不是来自浏览器的正常访问"。但 User-Agent 是客户端可以任意修改的请求头，本质上只是一个"可用性护栏"，从来不是一道真正的安全边界。

2. DNS 重绑定：把浏览器变成攻击者的"混淆代理"

真正让这个漏洞变得危险的，是攻击者把它和 DNS 重绑定（DNS Rebinding）技术结合了起来。DNS 重绑定攻击的基本原理是：攻击者控制一个域名的 DNS 解析记录，先让受害者浏览器解析到一个正常的公网 IP 完成页面加载和同源校验,然后迅速把该域名的 DNS 记录改指向 127.0.0.1 或受害者内网地址；由于浏览器的同源策略只看域名不看 IP，后续 JavaScript 发出的请求会被浏览器当作"同源请求"直接放行，实际上却打到了受害者本机或内网里正在监听的 Ray Dashboard 端口上。

攻击链条简化后是这样的：

1. 开发者的电脑上本地跑着 ray start --head，Ray Dashboard 监听在默认端口；
2. 该开发者浏览了一个被攻击者控制、或被恶意广告污染的网页；
3. 页面里的 JavaScript 利用 DNS 重绑定，绕过同源策略把请求发到 127.0.0.1 上的 Ray API；
4. 由于请求带着一个伪装成浏览器的 User-Agent，唯一的防护形同虚设；
5. 攻击者通过 /api/jobs 等接口提交恶意任务定义，Ray 直接在本机或集群上执行任意代码。

整个过程中，受害者除了"打开一个网页"之外不需要做任何操作，也不涉及任何凭证泄露——这正是它 CVSS 评分高达 9.4 的原因：攻击复杂度低、不需要权限、不需要用户交互（超出正常浏览行为）、影响范围是完整的机密性、完整性和可用性丧失。

3. 真实世界的攻击活动

这不是一个停留在概念验证阶段的漏洞。相关时间线大致如下：

• 2025 年 11 月：漏洞细节和 PoC 公开披露；
• 2025 年 11 月 26 日前两天：BitSight 报告显示，RondoDox DDoS 僵尸网络团伙已经将该漏洞纳入其攻击武器库，抢在公开披露之前完成了武器化；
• 持续进行中：名为 ShadowRay 2.0 的攻击活动专门扫描互联网上暴露的 Ray 实例，一旦发现装有 NVIDIA GPU 的未修补集群，就将其转化为自我复制的加密货币挖矿僵尸网络节点——这类集群往往算力可观，对挖矿攻击者而言是相当有吸引力的目标；
• 2026 年 8 月 17 日：CISA 正式将 CVE-2025-62593 加入 KEV 目录；
• 2026 年 8 月 20 日：FCEB 机构的强制修复截止日期（也就是本文发布当天）。

4. 修复方案：从"检查 User-Agent"到"真正的 Token 认证"

Ray 官方在 2.52.0 版本中给出了根本性修复：为 Dashboard、CLI、API 客户端和内部服务引入了内置的 Token 认证机制。启用方式是在启动集群前设置环境变量 RAY_AUTH_MODE=token，启用后所有外部 Ray API 和内部通信都会用该 Token 作为共享密钥进行认证。需要特别注意的是，Token 认证在 2.52.0 中默认是关闭的，也就是说仅仅升级版本并不能自动获得防护，团队必须主动开启这个开关才算真正堵上这个口子。

三、实践指南：给开发者和团队的排查与加固清单

结合 CISA 公告以及安全社区给出的应急响应建议，这里整理一份可以照着执行的排查清单。

第一步：确认自己的环境里有没有 Ray，版本是多少

# 检查当前环境安装的 Ray 版本
pip show ray | grep -E "Name|Version"

# 在项目依赖文件里搜索 ray 相关声明
grep -rn "ray" requirements.txt pyproject.toml Pipfile 2>/dev/null

# 扫描本机正在运行的 Ray 进程和监听端口
ps aux | grep "ray::" 
ss -tlnp | grep -E "8265|6379|10001"   # 8265 是 Dashboard 默认端口

Ray 经常以"影子基础设施"的形式潜伏在组织里——开发者本机手动 ray start --head、CI/CD 流水线里内嵌的调用、平台团队维护的容器基础镜像、Kubernetes 上的 KubeRay 部署、云厂商托管服务内部封装的 Ray、第三方 ML 平台自带的 Ray 运行时，都是常见的"未被资产清单记录"的来源，值得逐一排查。

第二步：升级并显式开启 Token 认证

# 升级到修复版本
pip install --upgrade "ray>=2.52.0"

# 启动集群时显式开启 token 认证（默认是关闭的，必须手动打开）
export RAY_AUTH_MODE=token
ray start --head --dashboard-host=127.0.0.1

注意最后一行的 --dashboard-host=127.0.0.1：即便升级并开启了 Token 认证，也建议把 Dashboard 绑定在 localhost，不要监听 0.0.0.0；确需远程访问时，在前面加一层做了正规认证和 TLS 的反向代理，而不是把 Ray 原生接口直接暴露到公网或不受信任的内网。

第三步：对外暴露面做一次真实验证

# 从外部网络确认 Dashboard 端口是否可被访问（应返回连接失败/拒绝）
curl -m 5 http://<你的服务器IP>:8265/api/jobs

如果这个请求能拿到正常响应，说明 Dashboard 处于暴露状态，需要立即调整防火墙规则或网络策略。

第四步：把 AI 基础设施纳入常规漏洞管理

这次事件也暴露了一个更普遍的问题：多数组织的资产清单和漏洞管理流程,是围绕"传统应用和服务器"设计的，Ray、Langflow、llama.cpp 这类 AI 计算框架既不像标准 Web 应用,也不像标准中间件，很容易在常规扫描中被漏掉。建议团队：

• 建立独立的 AI 基础设施清单，覆盖计算框架、编排工具、模型服务、Notebook 环境和 Agent 运行时；
• 把开发者工作站也纳入 AI 工具链的漏洞管理范围，而不只是盯着生产服务器；
• 订阅 CISA KEV 更新作为一条独立的运营信息流，并指定明确的分诊责任人；
• 把 AI 基础设施显式纳入渗透测试范围；
• 对内部服务默认强制要求认证（default-deny），而不是依赖文档里的"建议开启"。

四、总结与展望

CVE-2025-62593 表面上是一个具体框架的具体漏洞，但它折射出的问题要大得多：整整一代 AI 基础设施工具——Ray、Langflow、llama.cpp 乃至更多——诞生于"研究集群跑在防火墙后面"的假设之下，而今天它们被大规模部署在开发者笔记本、CI/CD 流水线、多租户云平台这些完全不同的信任边界里，安全模型却没有同步演进。CISA 用一个三天的联邦修复期限传递出的信号很明确：AI 计算框架不再是"边缘工具"，而是关键基础设施的一部分，监管和攻击者都已经把目光投向了这里。对于国内的 AI 团队而言，即便不直接受 FCEB 合规要求约束，这次事件也是一次很好的"免费体检"机会——花一个下午的时间盘点一下自己的 Ray 部署，很可能比事后处理一次挖矿僵尸网络入侵要划算得多。可以预见,随着 AI 基础设施的组件越来越多、集成越来越深，"下一个 Ray 级别的严重漏洞"大概率还会以类似的三天倒计时姿态出现,提前建立好资产清单和应急响应机制,才是真正的护城河。

参考来源

• CISA Flags Actively Exploited Ray Flaw That Can Trigger Browser-Based RCE — The Hacker News
• U.S. CISA adds a Ray-Project Ray flaw to its Known Exploited Vulnerabilities catalog — Security Affairs
• CISA Warns of Ray-Project Ray Code Injection Vulnerability Exploited in Attacks — Cyber Security News
• CISA Put an AI Compute Framework in the KEV Catalog and Gave Agencies Three Days — ComplianceHub.Wiki
• Release Ray-2.52.0 — ray-project/ray GitHub
• Ray token authentication — Ray 官方文档