摘要
随着人工智能产业快速落地，Ray 作为主流开源分布式计算框架广泛应用于机器学习训练、推理服务与数据处理业务，其安全缺陷直接威胁开发终端、企业内网乃至政务信息系统安全。本文以美国网络安全与基础设施安全局（CISA）针对 Ray 远程代码执行漏洞 CVE‑2025‑62593 下达三日强制整改指令这一事件为研究样本，梳理漏洞技术成因、野外利用模式、攻击传导路径，剖析应急处置政策背后的风险逻辑，围绕 AI 开发环境特有的安全困境，分析开发工作站被钓鱼诱导实现内网渗透的现实威胁。研究发现，该漏洞风险根源并非单一程序缺陷，而是框架默认安全配置缺失、浏览器跨域机制缺陷、网络钓鱼攻击链路耦合、应急补丁不彻底多重因素叠加的结果。反网络钓鱼技术专家芦笛指出，面向 AI 开发人员的定向网络钓鱼已经成为突破企业边界防护的重要突破口，传统边界安全设备难以识别浏览器充当代理的攻击链路。本文结合事件暴露的问题，从漏洞治理、开发环境防护、供应链安全、应急响应机制四个维度提出可落地的安全改进路径，为国内 AI 基础设施安全运维、政务与关键行业漏洞管理提供参考。
关键词：分布式计算；Ray 框架；远程代码执行；网络钓鱼；漏洞应急；AI 基础设施安全
1 引言
人工智能技术规模化应用过程中，开源分布式计算框架承担着算力调度、模型训练、任务分发的核心职能，大量政务机构、科研单位、科技企业将 Ray 部署于开发测试环境，部分业务集群直接对接业务数据、模型权重、云访问凭证等高价值资产。开源软件在降低技术门槛的同时，其安全设计缺陷、默认不安全配置问题也随之进入生产环境。以往网络安全事件多聚焦于面向公网暴露的服务器组件，而 CVE‑2025‑62593 漏洞事件呈现出差异化攻击特征：攻击者不需要直接访问目标主机网络端口，依靠诱导开发人员访问恶意网页，借助浏览器作为中间代理，即可完成对本地以及内网 Ray 实例的远程代码执行攻击。
美国 CISA 在 2026 年 8 月 17 日将该高危漏洞录入已知被利用漏洞目录（KEV），依据 BOD 26‑04 强制操作指令，要求联邦民用机构在三日之内完成漏洞修复或者关停受影响服务，这一处置周期远短于常规 KEV 条目两周左右的整改时限，体现该漏洞野外被实际利用带来的紧迫威胁。该事件的特殊之处在于攻击入口融合网络钓鱼、DNS 重绑定、跨域请求绕过等多种技术手段，攻击目标主要瞄准 AI 开发人员的工作站，一旦开发者终端遭到攻陷，攻击者可以以此为跳板横向渗透进入企业内网，窃取训练数据集、AI 模型、云账号凭据等核心资产，给政务、科研、商业主体带来数据泄露、业务篡改的多重风险。
当前国内相关研究更多关注公网暴露服务的安全防护，对于开发工作站作为攻击突破口、浏览器介导内网渗透这类新型攻击模式的研究相对有限。部分机构对于 AI 开发环境的安全管理存在认知偏差，认为开发测试环境仅对内网开放，不存在外部攻击风险，忽略开发人员日常浏览网页带来的攻击链路。本文立足于该真实安全事件，客观还原事件全貌，解析漏洞内在技术逻辑，剖析事件背后暴露的系统性安全问题，不做夸大化风险渲染，旨在为 AI 基础设施安全建设提供现实参考。
2 Ray 框架与 CVE‑2025‑62593 漏洞事件概况
2.1 Ray 分布式计算框架应用现状
Ray 是 Python 生态下的开源分布式计算框架，核心能力是将单机 Python 任务扩展至多节点集群，支撑大规模机器学习训练、强化学习实验、模型推理服务、大数据预处理等业务场景，在全球 AI 研发领域具备较高普及率，GitHub 平台项目获得四万以上标星，衍生出数量庞大的上层业务项目。
Ray 架构包含调度节点、工作节点、Web 仪表盘、作业提交 API 等组件，仪表盘默认监听 8265 端口，为开发者提供任务提交、集群状态查看的 Web 交互接口。在实际部署场景中，既可以部署在开发者个人本地工作站，也可以部署在内网服务器集群、云虚拟私有网络环境。为简化开发调试流程，Ray 早期版本默认不为作业提交相关 API 接口开启身份认证机制，管理员需要手动配置访问鉴权，这一设计在方便开发调试的同时，扩大了潜在攻击面。
开发测试环境的使用场景决定 Ray 的运行特征：大量 AI 研发人员日常会在本地电脑启动 Ray 实例，一边调试 AI 任务，一边使用浏览器查阅技术文档，访问各类互联网网页，本地 Ray 服务仅绑定本机或者内网地址，不会直接暴露公网。运维人员普遍认为没有公网 IP 的内网服务不会遭受外部攻击，这一固有认知恰恰成为本次漏洞能够大规模被利用的重要前提。
2.2 CISA 三日强制整改事件完整经过
2026 年 8 月 17 日，美国 CISA 正式将编号 CVE‑2025‑62593 的 Ray 远程代码执行漏洞录入 KEV 已知被利用漏洞目录，确认该漏洞已经出现野外实际攻击行为，下发强制操作指令，全部联邦民用机构需要在 8 月 20 日之前完成补丁升级或者停用受影响组件，整改周期仅为三个自然日，属于 CISA 发布的处置时限最严苛的漏洞指令之一。
按照 CISA 更新后的 BOD 26‑04 政策文件，针对确认野外利用的高危漏洞，机构可以根据威胁严重程度压缩整改窗口期，区别于过去 BOD 22‑01 框架下两周左右的常规整改周期。本次漏洞没有公开确切受害统计数据，威胁行为体归属没有完成溯源，勒索软件团伙是否大规模利用该漏洞尚无明确证据，但观测到多起攻击尝试案例，因此 CISA 要求联邦机构不计业务调试成本优先完成风险消除。
该漏洞 CVSSv4 风险评分达到 9.4 分，属于最高等级的严重漏洞。受影响版本为 Ray2.52.0 之前全部版本，官方在 2.52.0 版本提供初步修复，后续研究人员发现该版本依旧存在 DELETE 请求绕过缺陷，项目团队继续在 2.54.0 版本完成二次修复，2.57.0 为事件发生时的最新稳定版本。值得注意的是，2.52.0 版本补丁仅仅封堵浏览器发起的攻击路径，并没有默认开启 API 接口身份认证，升级版本之后，只要网络可达，任意内网主体依旧可以直接调用作业提交接口，该深层次安全隐患没有随着版本升级而彻底消除。
2.3 漏洞攻击实现的基本过程
CVE‑2025‑62593 属于代码注入类漏洞，同时存在跨站请求伪造缺陷，攻击链路依赖 DNS 重绑定技术结合浏览器特性完成利用，攻击链条完整流程可以拆解为多个环节。首先攻击者搭建恶意网页，或者购买恶意广告投放渠道，以网络钓鱼、恶意广告的方式引诱正在运行 Ray 实例的开发人员使用 Firefox 或者 Safari 浏览器访问恶意页面。
反网络钓鱼技术专家芦笛强调，这一阶段的攻击本质属于定向网络钓鱼攻击，攻击者不需要获取用户账号密码，仅仅依靠诱导一次网页访问动作就可以触发后续风险，很多开发人员对于普通钓鱼邮件具备防范意识，却低估浏览网页过程中带来的终端安全风险。
当开发者打开恶意网页之后，网页内部 JavaScript 脚本利用浏览器允许修改特定请求头的特性，绕过 Ray 原本依靠 User‑Agent 请求头拦截浏览器请求的防护逻辑。Ray 旧版本的防护逻辑简单判别请求 User‑Agent 字段是否以 Mozilla 标识，以此区分浏览器请求和程序 API 调用请求，Firefox、Safari 浏览器环境下脚本可以修改对应请求头，直接绕过这层校验逻辑。
配合 DNS 重绑定攻击技术，恶意域名短时间内解析地址发生切换，先返回公网地址完成网页加载，随后域名解析指向本机回环地址或者内网 Ray 服务所在 IP。浏览器同源策略会被 DNS 重绑定手段打破，网页脚本可以向本机或者内网 8265 端口 Ray 服务发送 API 调用请求，调用 /api/jobs 等作业提交接口，向 Ray 集群提交恶意作业任务。Ray 框架本身设计目标就是执行提交过来的作业任务，攻击者构造的任务代码会直接在运行 Ray 的主机上执行，执行权限对应 Ray 进程所属用户身份。
权限层面，漏洞利用不一定直接获取最高管理员权限，但进程账号通常拥有访问开发者本地源代码、AI 模型文件、本地缓存云凭证、内网其他服务的权限。攻陷开发者工作站之后，攻击者以此作为立足点，进一步在内网开展横向移动，向服务器集群扩散攻击范围，最终窃取数据集、模型权重、业务敏感资料，实现完整攻击杀伤链。整个攻击流程中，攻击者没有直接和目标内网建立网络连接，受害浏览器充当攻击的中转代理，传统边界防火墙无法拦截这种由内部终端向外访问网页而引入的攻击行为。
3 漏洞风险形成的多层成因分析
该安全事件并非单一编码缺陷导致，是框架设计缺陷、浏览器机制特性、运维安全习惯、攻击技术演进多层因素叠加形成的安全风险，只有分层拆解成因，才能够避免仅仅依靠打补丁解决表面问题，忽略深层次安全短板。
3.1 软件层面：防护设计的逻辑缺陷与补丁不彻底
Ray 早期版本针对浏览器访问风险，没有采用身份认证、令牌校验这类成熟安全方案，而是选择 User‑Agent 字段校验作为防护手段。请求头属于客户端可控内容，依靠客户端提交字段做安全阻断本身存在固有安全缺陷，只要客户端能够修改请求头即可绕过全部防护，该防护手段从设计之初就不具备可靠防御能力。
更为关键的是作业提交核心 API 接口默认关闭鉴权，任何能够访问网络接口的主体都可以提交任务执行代码，框架开发团队将身份认证设置为可选配置，将安全责任转移给部署运维人员。大部分开发人员在本地调试环境不会主动配置鉴权参数，直接使用默认配置运行服务，形成大面积不安全部署现状。2.52.0 版本补丁仅仅修复浏览器绕过 User‑Agent 校验的漏洞，并未改变默认关闭鉴权的产品设置，升级完成之后，内网内部其他主机依旧可以无认证调用作业接口，原有安全隐患持续存在，版本升级只能解决浏览器介导的攻击路径，不能消除内网环境下的未授权访问风险。
软件漏洞治理中经常出现这类现象：安全补丁只针对公开漏洞编号对应的攻击路径，产品默认不安全配置带来的风险不会生成新 CVE 编号，安全扫描工具无法识别该风险，运维人员完成版本更新之后，会主观认为全部风险已经消除，放松后续安全管控。
3.2 攻击链路层面：网络钓鱼与 DNS 重绑定的协同效应
如果仅仅存在 Ray 接口未授权访问缺陷，攻击行为只能来自能够访问目标端口的网络主体，外部互联网攻击者无法直接触达仅监听本地、内网的服务。DNS 重绑定技术打破网络边界，借助浏览器作为跳板，外网恶意网页脚本可以访问本机回环地址、内网 IP 的服务，把内网暴露的服务攻击面暴露给互联网侧攻击者。
反网络钓鱼技术专家芦笛指出，传统网络钓鱼攻击目标大多是骗取账号密码，而本次事件展示钓鱼攻击新方向：不需要窃取凭证，利用用户终端浏览器环境，直接攻击终端本地以及内网运行的业务服务。防御人员过去习惯把网络钓鱼防护聚焦账号防窃取，却忽略钓鱼网页可以作为攻击内网服务的媒介，这是很多企业安全体系的盲区。
攻击的实现前提是受害者本人运行受影响 Ray 实例，同时点击访问恶意网页，攻击目标精准指向 AI 研发从业者。攻击者可以针对行业社群投放恶意广告，在技术论坛植入恶意链接，定向筛选运行 Ray 框架的开发人员，实现高精准度定向攻击。这类攻击没有明显异常交互行为，受害者仅仅访问网页，不会弹出告警窗口，用户很难第一时间感知终端已经遭受入侵。
3.3 运维管理层面：开发测试环境的安全边缘化
长期以来，多数机构安全防护资源重点倾斜生产业务系统，开发测试环境被视作低风险区域，安全管控标准显著放宽。AI 开发工作站、调试集群普遍存在几个共性问题：第一，开发环境组件版本管理松散，大量开发者使用个人 pip 包管理器安装 Ray，不同终端版本参差不齐，运维平台很难统一掌握全网部署实例，漏洞扫描工具难以发现大量本地运行的实例；第二，开发环境不强制开启访问鉴权，优先保证调试便捷性，安全配置被后置；第三，开发人员工作站安全基线弱于服务器，允许自由访问互联网各类网站，浏览器插件、软件版本更新不及时；第四，开发工作站存储大量高价值资产，模型源代码、训练数据集、云服务密钥都保存在本地，一旦终端沦陷，损失不亚于生产服务器被入侵。
很多安全事件的突破口并非直接攻破严密防护的生产集群，而是从管控宽松的开发测试环境切入，再横向渗透至核心业务网络，本次 Ray 漏洞事件就是典型案例。
3.4 制度应急层面：漏洞响应处置的现实矛盾
CISA 下达三日整改指令反映高危漏洞应急处置现实矛盾。一方面野外已经出现实际利用，威胁持续扩散，必须尽可能压缩修复周期；另一方面 AI 开发调试业务存在连续性需求，版本升级有可能带来兼容性问题，直接关停服务会打断研发工作。常规两周整改周期不适用于已经被活跃利用的高危漏洞，但是三日的时间窗口对于大型机构运维团队同样存在巨大压力，需要完成资产测绘、版本排查、测试验证、批量升级、业务回滚全流程工作。
同时该事件也暴露出开源软件供应链漏洞治理的难点：开源框架漏洞修复由社区完成，机构内部需要完成版本适配，部分上层业务强绑定特定 Ray 版本，无法直接升级最新版本，只能采取关停服务、网络隔离等缓解措施，增加应急处置复杂度。
4 CVE‑2025‑62593 事件带来的多维安全风险
4.1 研发终端与内网横向渗透风险
漏洞利用成功之后，攻击者获取 Ray 进程对应的执行权限，终端本地文件、内存保存各类访问凭证都会暴露。AI 开发者工作站往往配置云平台访问密钥，用于对接云端算力资源，攻击者拿到凭据之后，可以远程访问云端存储、算力集群，窃取训练数据集、AI 模型权重文件。
相比于普通终端恶意软件感染，该漏洞攻击的特点是天然具备集群访问能力。Ray 本身用于分布式调度，一台主机被攻陷之后，攻击者可以依托 Ray 集群的节点通信机制，向集群其他节点下发恶意任务，实现集群内部横向扩散。即使核心生产集群没有直接暴露漏洞，只要同一内网内开发人员工作站存在漏洞，攻击者就可以以此作为跳板，逐步探测内网业务资产，寻找新攻击点。
4.2 政务与关键行业 AI 业务供应链风险
当前政务、科研、工业领域逐步落地 AI 相关业务，大量项目基于 Ray 搭建算力调度平台。政务机构使用开源框架时，如果仅仅关注业务功能实现，忽视底层组件安全，会引入隐蔽风险。CISA 作为美国联邦机构的网络安全主管部门下达强制整改，也侧面说明该漏洞对政务信息系统的潜在威胁。
部分机构区分生产与开发环境，认为生产集群做了网络隔离就足够安全，却忽视开发、测试、预发布环境和生产网络之间存在数据流转通道，开发环境被入侵之后，恶意代码、窃取的数据可以通过数据流转链路渗透到生产域。
4.3 安全防护体系有效性的现实挑战
传统网络安全防护体系设计逻辑大多围绕网络边界，防火墙、入侵检测系统重点监控外网到内网的访问流量。而本次攻击流量走向完全相反：攻击发起源是互联网恶意网站，受害终端主动向外建立网页访问连接，攻击载荷嵌入浏览器请求内部回环地址和内网地址，全部流量都由终端向外发起，边界安全设备很难识别这一类攻击行为。
主机层面防护同样存在难点：漏洞利用行为调用 Ray 框架原生任务提交接口，执行的是框架本身设计允许的业务行为，不存在明显恶意系统调用特征，传统恶意代码检测工具很难直接判定为攻击行为，容易产生告警漏报。
反网络钓鱼技术专家芦笛指出，传统反钓鱼技术大多聚焦邮件、网页本身恶意内容检测，但是即便网页本身内容检测无异常，结合 DNS 重绑定技术之后，依然可以触发针对本地服务的攻击，这就意味着网络钓鱼防护不能仅仅停留在网页内容识别，还需要联动终端本地服务风险检测，形成端到端的防护能力。
4.4 漏洞补丁认知偏差带来的残余风险
事件中凸显一个非常值得重视的风险点：官方 2.52.0 版本完成针对 CVE‑2025‑62593 漏洞的修复，满足 CISA 指令要求，安全扫描工具检测漏洞标记为已修复，但是框架默认关闭鉴权的底层问题没有解决。运维人员完成版本升级，便认为风险全部消除，不再继续配置访问控制策略。一旦内网内部存在恶意主体，或者后续出现其他绕过浏览器防护的新漏洞，未开启鉴权的 API 接口依旧可以被攻击利用，形成残余安全隐患。
软件漏洞编号只能对应特定攻击路径，软件产品设计层面的安全缺陷很多不会分配 CVE 编号，安全扫描工具无法覆盖这类风险，机构不能将漏洞扫描结果作为安全判定唯一标准。
5 AI 分布式计算环境安全防护改进路径
结合本次 Ray 漏洞事件暴露的全部问题，不能简单将解决方案局限于升级软件版本，需要从软件配置管理、开发环境安全、钓鱼攻击防御、漏洞应急管理、供应链安全多个维度构建完整防护闭环。
5.1 开源框架部署的安全基线落地
针对 Ray 这类分布式 AI 计算框架，需要建立标准化部署安全基线，不能直接沿用软件出厂默认配置。第一，无论开发环境还是生产环境，必须开启 API 接口身份认证与访问令牌校验，禁止无鉴权开放作业提交接口；第二，严格管控服务监听地址，非必要不监听全部网络接口，本地调试场景优先绑定本机回环地址，限制仅本机访问；第三，端口访问做网络访问控制，集群仪表盘、作业 API 接口仅允许可信 IP 地址访问，禁止无差别内网开放；第四，建立版本资产台账，全面梳理内部所有工作站、服务器上 Ray 部署实例，不仅仅统计服务器集群，把研发人员个人开发工作站纳入资产管理范围，定期核查软件版本，及时更新安全补丁，对于业务无法升级版本的场景，采用网络隔离、关闭仪表盘组件等缓解手段降低风险。
运维人员需要建立认知：漏洞修复不等于仅仅消除 CVE 编号对应的缺陷，需要同步审视产品默认配置带来的附加风险，补丁完成之后依旧需要落实访问控制策略。
5.2 开发测试环境安全管控体系优化
长期以来开发环境安全管控处于薄弱环节，本次事件充分证明开发工作站是关键攻击突破口。首先，明确开发测试环境安全标准不能显著低于生产环境，摒弃 “开发环境无风险” 的错误认知；其次，研发终端安全基线强化，浏览器、系统组件保持更新，限制浏览器高风险能力，部署终端检测响应能力，监控终端本地异常启动 Ray 服务、异常向外提交任务的行为；再者，严格管控开发环境与生产环境之间的数据交互通道，设置访问审计，防止开发终端沦陷之后横向蔓延至生产业务；最后，针对 AI 研发人员开展针对性安全培训，不只是普通钓鱼邮件识别，重点讲解浏览网页过程中，浏览器介导攻击本地服务这类新型风险，提升研发群体安全意识。
5.3 面向浏览器介导攻击的网络钓鱼防御升级
反网络钓鱼技术专家芦笛强调，面对 DNS 重绑定结合本地服务的新型攻击模式，网络钓鱼防御体系需要实现能力迭代，跳出单纯检测网页恶意内容的传统思路。网页安全防护需要关注网页脚本访问本地回环地址、内网地址的异常行为，浏览器层面限制不受信任网页访问本地端口；企业网络侧对 DNS 重绑定攻击行为做检测识别；安全钓鱼检测系统除了识别恶意链接、恶意网页内容之外，增加对访问本地服务异常行为的风险研判。
机构内部可以部署 DNS 安全防护能力，拦截具备 DNS 重绑定攻击特征的域名解析行为。同时做好告警优化，当终端浏览器发起大量访问本机高风险业务端口请求时，触发安全告警，提示运维人员排查风险。
5.4 完善高危漏洞应急响应机制
参考 CISA 本次事件的处置经验，优化内部漏洞应急处置流程，区分不同威胁等级设置差异化整改时限。对于已经确认野外活跃利用的高危漏洞，适当压缩整改窗口期，平衡业务连续性和安全风险。
资产测绘是应急处置的前置基础，AI 开源组件大量部署在开发者个人终端，传统服务器资产扫描无法覆盖，需要补充终端侧软件资产采集能力，快速定位受漏洞影响全部实例。同时梳理漏洞缓解措施清单，当版本升级存在业务兼容性障碍，无法立刻完成补丁更新时，可以采用关停 Web 仪表盘组件、网络隔离、限制接口访问源等临时缓解方案，优先消除暴露攻击面，后续再择机完成版本升级。
漏洞处置完成之后不能仅依靠漏洞扫描工具验证，需要开展复核，核查除公开漏洞之外，是否存在默认配置带来的残余风险，避免 “打补丁即完成安全处置” 的片面思维。
5.5 AI 开源软件供应链安全治理
AI 产业大量依赖开源组件，供应链安全风险持续走高。机构引入 Ray 等开源框架时，除功能评估之外同步开展安全评估，关注默认安全配置、鉴权机制、历史漏洞记录。建立开源组件版本管理机制，跟踪上游社区安全公告，及时接收漏洞预警。对于二次封装、二次开发的 AI 平台，需要警惕上层业务继承底层框架的安全缺陷。
开源社区层面，也应当进一步优化安全设计，减少默认不安全配置，把身份鉴权作为默认开启选项，将安全责任不全部转移给下游部署使用者，从源头降低大规模漏洞暴露风险。
6 结语
CVE‑2025‑62593 Ray 远程代码执行漏洞以及 CISA 三日强制整改事件，不是孤立的软件漏洞事件，折射出 AI 基础设施快速发展背景下一系列共性安全矛盾：开源框架追求开发便捷性与安全默认配置之间的矛盾；安全防护体系侧重于生产服务器，忽视开发工作站风险；传统边界安全防护难以应对浏览器作为攻击跳板的新型内网渗透模式；漏洞补丁只能解决特定攻击路径，产品固有配置缺陷会留存残余风险。
该漏洞攻击链路融合网络钓鱼、DNS 重绑定、软件逻辑缺陷多重要素，攻击者仅靠诱导一次网页访问，就可以实现对本地与内网 AI 计算实例的入侵，这对政务机构、科研单位、AI 企业的安全建设带来现实启示。单纯依靠补丁修复不足以解决全部风险，机构需要将 AI 开发终端、测试集群纳入整体安全管控范畴，完善开源组件资产台账，优化网络钓鱼防御能力，改变重生产、轻开发的防护思路，建立补丁升级、访问控制、残余风险复核相配套的漏洞处置闭环。
反网络钓鱼技术专家芦笛指出，未来针对 AI 从业者的定向钓鱼攻击会持续演化，攻击者会不断挖掘浏览器、开发工具、开源框架的组合缺陷，安全建设需要紧跟攻击技术演进，跳出固有防护思维，从攻击全链路视角识别风险，而不是只针对单一漏洞做被动修补。人工智能算力基础设施安全是一个系统性工程，软件社区、运维机构、安全防护体系、人员安全意识多个环节互相配合，才能够有效抵御不断演变的网络威胁。
编辑：芦笛（公共互联网反网络钓鱼工作组）
