事件概述
CISA 在 2026 年 8 月 17 日将 Ray 的代码注入漏洞 CVE-2025-62593 列入 Known Exploited Vulnerabilities（KEV）目录，意味着该漏洞已经被确认存在利用活动，不能再只按“理论风险”处理。Ray 官方在 GitHub 安全公告 GHSA-q279-jhrf-cc6v 中将问题描述为一个可被浏览器场景触发的严重远程代码执行风险，影响使用 Ray 作为开发、测试或分布式计算工具的开发者和团队。
这次问题的关键不在于“公网暴露一个管理后台才危险”这么简单。官方公告提到，漏洞可结合 DNS rebinding 思路，通过 Safari、Firefox 等浏览器场景影响开发者机器；同时，浏览器也可能被当作“中间跳板”，去触达企业内网中原本不对公网开放、但对员工电脑可达的 Ray 实例。对很多中小团队来说，这类开发/测试组件往往不在传统资产清单里，反而容易漏补丁、漏访问控制。
影响范围
根据 Ray 官方公告，受影响版本为 Ray 2.52.0 之前版本，修复版本为 2.52.0。公告给出的影响场景主要是开发者运行 Ray 开发或测试环境时，如果遭遇钓鱼页面、恶意广告或其他可诱导浏览器访问的内容，攻击者可能进一步在开发机上执行任意 shell 代码。CISA KEV 条目也将该漏洞描述为代码注入漏洞，可导致远程代码执行。
需要重点排查的不是“所有装过 Python 的机器”，而是实际运行 Ray、Ray Dashboard、Ray Serve、Ray 集群控制面或相关开发服务的环境。尤其是开发机、跳板机、CI/CD 构建机、内网测试服务器、AI 训练/推理实验节点，以及曾经为了调试方便把端口绑定到 0.0.0.0 的临时实例，都应该纳入排查范围。
为什么运维和开发团队要关注
Ray 常见于机器学习、数据处理、分布式任务和实验性平台中，很多实例并不是由传统运维统一部署，而是由开发者在本机、测试机或云主机上临时拉起。这样的服务通常有三个风险点：版本更新不跟随生产系统补丁节奏，访问控制依赖默认配置，端口暴露情况缺少统一巡检。
这类漏洞真正麻烦的地方，是它把“浏览器访问网页”和“内网开发服务”连在了一起。哪怕 Ray 实例没有直接暴露在公网，只要员工终端能访问到它，浏览器被诱导后就可能成为攻击链的一部分。对企业来说，开发机一旦被打穿，后续风险可能扩展到源码、凭据、数据集、模型文件、对象存储密钥和内网服务凭据，影响面往往超过单台电脑本身。
排查思路
第一步是确认资产。团队可以从开发机、测试服务器、容器镜像、CI 构建脚本、Notebook 环境、Kubernetes Job、systemd 服务和历史部署文档里检索 Ray 使用痕迹。只要发现有 Ray 运行记录，就应进一步确认版本、监听地址、端口暴露范围和是否允许未授权访问。
第二步是确认版本。Python 环境中可以优先通过包管理工具、虚拟环境或项目依赖文件核对 Ray 版本，例如检查 requirements、poetry.lock、conda environment、Dockerfile 和镜像构建日志。临时命令可以用于辅助确认，但不要只依赖单台机器的交互结果；生产和测试镜像、长期运行的容器以及开发者本地虚拟环境都可能版本不一致。
第三步是确认暴露面。Ray 相关服务不应直接暴露到公网，也不应在没有认证和网络隔离的情况下被整个办公网访问。需要重点检查安全组、防火墙、Kubernetes Service、Ingress、反向代理、SSH 隧道和端口转发配置，确认管理端口只对必要主机开放。
修复和缓解建议
官方修复路径是升级到 Ray 2.52.0 或更高版本。对单机开发环境，升级前先确认当前项目依赖约束和 Python 版本兼容性；对团队环境，应先在测试环境验证任务提交、Dashboard、Ray Serve、调度逻辑和模型依赖是否正常，再安排生产或共享环境升级。不要在未评估业务影响的情况下直接重启关键计算任务。
如果短时间内不能完成升级，至少应临时收敛访问面：停止不必要的 Ray 服务；把监听地址限制在本机或受控网段；关闭公网安全组入口；禁止通过 Ingress、反向代理或端口转发暴露 Ray 管理端口；对开发机加强浏览器安全策略和钓鱼防护；同时检查近期是否有异常任务、陌生进程、可疑 shell、异常网络连接和新增凭据文件。
Ray 2.52.0 同时引入了默认关闭的 token authentication 能力，团队可以结合官方文档评估是否开启。需要注意的是，认证不是升级的替代品，网络隔离也不是补丁的替代品；比较稳妥的做法是“升级版本、限制暴露、最小权限、日志审计”一起做。
后续观察
CISA KEV 给出的处置时限很近，说明官方对该漏洞的风险优先级判断较高。安全团队后续应关注 Ray 官方公告、修复提交和各发行镜像的更新情况，也要留意容器基础镜像、Notebook 平台、MLOps 平台或内部工具是否间接捆绑了旧版 Ray。
这起事件也提醒团队：开发/测试组件不是“低价值资产”。只要它能访问源码、凭据、内网接口或云资源，它就应该进入补丁管理和暴露面治理流程。对中小企业来说，不需要把流程做得很复杂，但至少要知道哪些服务在跑、谁能访问、版本是否落后、出了问题能从哪里查日志。
信息来源
本文主要参考 CISA Known Exploited Vulnerabilities 目录中 CVE-2025-62593 条目、Ray 官方 GitHub 安全公告 GHSA-q279-jhrf-cc6v，以及 Ray 2.52.0 修复提交与官方 token authentication 文档。具体影响版本、修复版本和缓解措施应以 Ray 官方公告为准。
