防线只有一行 User-Agent 判断
Ray 是被广泛用于 AI 训练与推理的开源框架，它的面板和 API 长期把「浏览器发来的请求」当成需要挡住的一类。2.52.0 之前，这个判断依据是 HTTP 的 User-Agent 头是否以 Mozilla 开头——而这个头浏览器自己就能改。攻击者把它和 DNS 重绑定组合起来，只要开发者在跑着 Ray 的机器上访问一个恶意网页、甚至只是加载一条恶意广告，就能实现远程代码执行。漏洞归类为 CWE-94 代码注入，同时关联 CWE-352 跨站请求伪造。 Ray 维护者 2025 年 11 月的公告把根因说得更直白：/api/jobs、/api/job_agent/jobs/ 这些关键端点长期没有实现认证，是一个延续已久的设计选择。被攻陷的浏览器还能当「混淆代理」，去打企业内网里网络可达的其他 Ray 实例——这意味着单台开发机失守，波及面是整个内网的 Ray 集群。
从概念验证变成在野利用
8 月 17 日 CISA 把该 CVE 的 SSVC 状态从「概念验证」改为「在野利用」，并附上 Bitsight 关于 RondoDox 僵尸网络的研究。按 Bitsight 的说法，RondoDox 从 2025 年 11 月 24 日就开始尝试利用这个漏洞——比 CVE 在 11 月 26 日公开还早两天。该问题也与 ShadowRay 2.0 一类攻击关联。
难点在于找到它装在哪
修复本身简单：升级到 2.52.0 或更高版本，此前所有版本受影响。麻烦的是资产盘点——Ray 通常不是以传统企业软件的形式安装，而是作为一个 Python 包躺在各种 AI/ML 环境里。要查的地方包括开发者本机、容器镜像、Kubernetes 集群和云上 AI 基础设施，任何一处漏掉都等于没修。 顺带一条更普遍的教训：把「不可信来源」的判断建立在客户端可控的字段上（User-Agent、Referer 之类），等同于没有判断。这类框架的默认部署里，给面板和 API 加上真正的认证，比继续给绕过手法打补丁更值得投入。