Ray 分布式框架 CVE-2025-62593 远程代码注入漏洞已被积极利用

分布式计算框架已成为现代人工智能和机器学习管线的基石。在这些框架中，由 Anyscale 开发的 Ray 已成为扩展计算密集型工作负载的事实标准，涵盖大语言模型的分布式训练、高吞吐量强化学习以及实时模型服务等领域。然而，Ray 的快速采用暴露了一个系统性的架构盲点：即在历史上优先追求原始性能和开发者便利性，而忽视了严格的零信任安全边界。

这种矛盾已导致现实环境中的主动利用。美国网络安全和基础设施安全局（CISA）最近将 CVE-2025-62593——一个 Ray 中的关键远程代码注入漏洞——加入了已知被利用漏洞（KEV）目录。该漏洞允许未认证的攻击者在整个 Ray 集群中执行任意代码，有效地将高性能计算环境转变为横向移动、知识产权窃取和加密劫持的发起点。

作为一名资深技术编辑和系统架构师，我观察到各类组织反复陷入一个陷阱：在生产环境中使用默认的、面向开发的配置来部署复杂的分布式系统。在本文中，我将分析 CVE-2025-62593 的架构根本原因，剖析该漏洞的利用机制，并提供具体的、生产级别的缓解策略来保护你的分布式 AI 基础设施。这不是一项理论练习；如果你在生产环境中运行 Ray，你必须假设你的环境是一个目标，并立即采取系统性行动来隔离和保护你的计算节点。

深入架构分析 CVE-2025-62593，一个 Ray 分布式计算框架中的关键代码注入漏洞。了解漏洞利用机制、Ray 的信任模型如何被破坏，以及如何防御主动攻击。

🏗️ 理解 Ray 架构与攻击面

要理解 CVE-2025-62593 为何如此具有破坏性，我们必须首先审视 Ray 集群的基本架构。Ray 旨在抽象掉分布式系统的复杂性，允许开发者编写能够跨数千个 CPU 和 GPU 核心无缝运行的 Python 代码。为实现这一目标，Ray 依赖于高度互联的多组件拓扑结构。

任何 Ray 集群的核心是 Head Node。 head node 运行着几个关键的 control plane 服务：

Global Control Store（GCS）：一个键值存储（历史上基于 Redis，现为自定义 C++ 服务），负责管理集群元数据、actor 注册和对象位置。

API Server / Job Submission Service：一个 HTTP 端点（通常监听端口 8265），允许开发者提交作业、上传运行时环境并监控集群状态。

Ray Dashboard：一个基于 Web 的用户界面（同样共享端口 8265），用于可视化资源利用情况、日志和活动任务。

Ray Client Server：一个端点（通常在端口 10001 上），允许远程交互式 Python 会话直接连接到集群。

围绕 head node 的是 Worker Node。每个 worker node 运行一个本地 raylet 进程，该进程管理本地调度、对象存储（Plasma）以及执行实际 Python 任务的 worker 进程。

该设计的架构漏洞在于其信任模型。Ray 最初是为可信的、隔离的学术或私有网络环境而设计的。默认情况下，Ray 假定任何能够与 head node 端口通信的实体都被授权执行任意代码。Ray 核心协议中没有内置原生的、细粒度的基于角色的访问控制（RBAC）。如果攻击者能够访问 dashboard、job submission API 或 GCS 端口，他们就可以指示集群生成任务、下载外部包，并以 Ray 进程的权限运行任意 shell 命令。

当组织在云基础设施（如 AWS、GCP 或 Azure）或 Kubernetes 集群（使用 KubeRay operator）上部署 Ray 而没有严格的网络隔离时，他们会在不经意间将这些高度敏感的 control plane 端口暴露给公共互联网或已受损的内部网络。这种暴露正是威胁行为者正在针对的目标——以利用 CVE-2025-62593。

剖析 CVE-2025-62593：注入的机制

CVE-2025-62593 漏洞本质上是 Ray Dashboard 和 Job Submission API 中输入验证和边界执行的失败。具体来说，该漏洞位于 Ray head node 处理传入请求以配置"运行时环境"（runtime_env）的方式中。

在 Ray 中，runtime_env 允许开发者动态指定依赖项——如 pip 包、环境变量、conda 环境或远程 zip 文件——这些必须在作业执行前安装在 worker node 上。这是机器学习工作流程的强大功能，因为不同作业可能需要冲突版本的库。

然而，该功能的实现未能对 API payload 中传递的参数进行清理和验证。当客户端提交带有自定义 runtime_env 的作业时，head node 解析配置并执行系统级命令来准备环境（例如，调用 pip install 或解压下载的存档）。

由于 CVE-2025-62593 的存在，攻击者可以精心构造一个恶意 HTTP POST 请求，发送到 /api/jobs/ 或 dashboard 端点，其中包含嵌入在 runtime_env 参数中的 shell 元字符或恶意 payload。head node 在没有充分清理的情况下执行这些命令，导致任意代码执行。

由于 head node 负责编排整个集群，一旦攻击者在 head node 上实现代码执行，他们就可以轻松地将恶意 payload 传播到所有连接的 worker node。攻击者可以利用 Ray 原生的任务分发机制在整个 GPU 集群上执行命令，绕过任何仅监控边缘服务器的端点检测和响应（EDR）工具。

该漏洞特别隐蔽，因为它默认不需要身份验证。如果 Ray dashboard 端口（8265）可访问，任何外部行为者都可以发送单个 HTTP 请求来破坏整个计算集群。这使得 Ray 集群成为寻求大规模计算资源进行加密挖矿或试图窃取专有训练数据和模型权重的威胁行为者的主要目标。

架构层面的缓解：强化 Ray 集群

缓解 CVE-2025-62593 需要采用多层次的、零信任的系统架构方法。你不能仅依赖软件补丁；你必须在你 infrastructure 的设计中将应用程序层可能包含未修补漏洞作为前提。

我建议实施严格的纵深防御策略，包括网络隔离、强身份验证和运行时遏制。

1. 网络隔离与微分段

最有效的控制措施是确保没有任何 Ray control plane 端口可以从你的可信网络边界外部访问。你必须阻止所有对端口 8265（Dashboard/API）、10001（Ray Client）和 6379（GCS）的外部访问。

如果你通过 KubeRay operator 在 Kubernetes 上运行 Ray，你应该强制执行严格的 NetworkPolicy 来限制进入 head node 的入口流量。以下是一个生产级别的 Kubernetes NetworkPolicy，它限制对 Ray dashboard 和 API 的访问，只允许来自指定入口控制器或安全 bastion host 命名空间的连接：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-ray-head-ingress
  namespace: ml-workloads
spec:
  podSelector:
    matchLabels:
      ray.io/node-type: head
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx
    ports:
    - protocol: TCP
      port: 8265
  - from:
    - podSelector:
        matchLabels:
          ray.io/node-type: worker
    ports:
    - protocol: TCP
      port: 6379
    - protocol: TCP
      port: 10001

2. 实施认证反向代理

默认情况下，Ray Dashboard 不支持身份验证。要安全地向数据科学家开放 dashboard，你必须将其置于认证反向代理后面。

我建议部署 OAuth2 Proxy 或与你的身份提供商（IdP）通过 OIDC 集成的入口控制器（如 Okta、Azure AD 或 Keycloak）。代理拦截所有发往端口 8265 的流量，验证用户的身份和组成员身份，并且只将已认证的请求转发到 Ray head node。

此外，如果你使用 Ray Job CLI 或 Python SDK 提交作业，你应该在整个集群中配置 mutual TLS（mTLS）。Ray 支持所有内部通信通道（gRPC、GCS 和对象管理器）的 TLS 加密。你必须在所有节点上生成安全证书并配置以下环境变量：

3. 最小权限与容器强化

许多组织在 Docker 容器内以 root 用户身份运行 Ray 进程。这是一种危险的反模式。如果攻击者利用 CVE-2025-62593，他们会立即继承 root 权限，从而允许他们逃逸容器、破坏主机操作系统并访问云提供商元数据服务（这可能泄露 IAM 凭证）。

为降低此风险，请应用以下容器强化实践：

以非 Root 身份运行：配置你的 Dockerfiles 和 Kubernetes PodSecurityContexts，以非特权用户（例如 UID 1000）身份运行 Ray 进程。

只读根文件系统：将容器的根文件系统挂载为只读，为 Ray 的临时目录（/tmp/ray）使用专用的、不可执行的 emptyDir 卷。

禁用权限提升：在 Kubernetes 安全上下文中设置 allowPrivilegeEscalation: false。

限制云元数据访问：使用网络策略或本地 iptables 规则阻止对云元数据服务（例如 169.254.169.254）的访问，以防止凭证泄露。

监控、检测与事件响应

即使有强大的预防控制，你也必须建立持续监控，以检测潜在的攻击尝试和入侵后的行为。

⚙️ 日志分析与异常 API 活动

你应该集中化并分析来自 Ray Dashboard 和 Job Submission 服务的日志。查找发往 /api/jobs/ 或 /api/packages/ 的异常 HTTP POST 请求。具体检查这些请求的 payload 中是否包含：

意外出现的 shell 命令、管道字符（|）、分号（;）或反引号（`）在 runtime_env JSON 结构内。

试图从不受信任的外部域下载文件（例如，在 pip 依赖规范中使用 curl 或 wget）。

来自意外 IP 地址或公司 VPN 范围之外的请求。

🔐 运行时安全与进程监控

由于 CVE-2025-62593 导致任意代码执行，因此最可靠的入侵指标（IoC）是计算节点上的异常进程行为。

我建议在你的 Kubernetes 节点上部署基于 eBPF 的运行时安全工具，如 Cilium Tetragon 或 Falco。配置规则以对 Ray worker 或 head 进程生成的可疑子进程发出警报。例如，Ray worker 进程（raylet 或 Python worker）永远不应该生成 shell（/bin/sh、/bin/bash）、发起出站 SSH 连接或执行加密挖矿二进制文件。

如果你检测到主动入侵，请立即执行你的事件响应手册：

隔离：撤销受影响集群的网络安全组规则或 Kubernetes NetworkPolicy，以防止横向移动。

快照：对受影响节点的内存和持久磁盘进行快照，以进行取证分析。

终止：销毁被入侵的 Ray 集群。由于 Ray 工作负载通常是无状态的或检查点到外部对象存储（如 S3），因此从干净的、打过补丁的镜像终止并重新创建集群是最快的恢复路径。

轮换凭证：立即轮换任何可供被入侵集群访问的云 IAM 密钥、数据库凭证或 API 令牌。

CVE-2025-62593 是一个鲜明的提醒：AI 创新的快速步伐不能超越基础安全工程。像 Ray 这样的分布式计算框架非常强大，但其固有设计优先考虑计算效率而非隔离。当这些系统在没有严格架构保障的情况下部署时，它们为复杂的威胁行为者呈现了一个极具吸引力的目标。

要保护你的环境，你必须摆脱内部网络是安全的这一假设。实施网络微分段，对所有 dashboard 和 API 端点执行严格身份验证，以最小权限运行工作负载，并部署运行时监控以捕获异常行为。通过对你的分布式 AI 基础设施采用与核心事务系统相同的安全严格标准，你可以在不使你的组织面临灾难性入侵风险的情况下，充分利用分布式机器学习的全部力量。

🔗 Originally published on ixuvo.com