Red Hat OpenShift AI 漏洞导致完整基础设施被接管
严重的 OpenShift AI 漏洞允许低权限用户升级为集群管理员，存在数据窃取和基础设施控制风险。
新披露的红帽 OpenShift AI 漏洞可能允许低权限用户提升权限并完全控制混合云基础设施。
该漏洞被分配了接近满分的 CVSS 9.9 分，突显了其对于依赖 OpenShift AI 运行预测性和生成性 AI 工作负载的组织的严重性。
“拥有访问认证账户（如使用 Jupyter notebook 的数据科学家）的低权限攻击者可以将其权限提升为完整的集群管理员，“该公司表示。
漏洞可能危害 AI 工作负载
OpenShift AI 被广泛用于跨混合云环境管理机器学习模型的生命周期。
受影响的版本——OpenShift AI 2.19 和 2.21，以及红帽 OpenShift AI Operator 镜像——对于部署大规模 AI 管道的组织至关重要。
利用此漏洞（CVE-2025-10725）可能使攻击者窃取敏感数据、中断工作负载并危害底层基础设施，使敏感数据和关键操作面临风险。
低权限，完全接管：CVE-2025-10725 内部解析
CVE-2025-10725 的核心是一个配置错误的 ClusterRoleBinding，它将 kueue-batch-user-role 绑定到广泛的 system:authenticated 组。这种设计疏忽基本上将提升的权限扩展到了集群中的每个认证用户，而不是将其限制在严格定义的角色中。
实际上，大多数用户——例如在 Jupyter notebook 中运行实验的数据科学家——应该只有提交或管理自己工作负载的有限权限。但有了这个绑定，即使是低权限账户也可以调用 batch.kueue.openshift.io API 并创建任意的 Job 或 Pod 资源。
一旦建立了这个立足点，攻击者可以通过注入恶意容器或 init-containers 来链接权限。这些恶意工作负载可以运行管理命令，如 oc 或 kubectl，模拟更高权限的账户并逐步升级，直到达到 cluster-admin 角色。
拥有 cluster-admin 权限，攻击者拥有不受限制的控制权，可以执行以下操作：
- 窃取数据：访问和窃取集群存储中的机密、数据集和知识产权。
- 中断服务：终止 Pod、停止作业或部署降低或拒绝操作的服务。
- 控制基础设施：更改集群配置、安装持久后门或转向其他云资源。
虽然利用需要认证账户，但门槛相对较低。实际上，单个受损或内部账户可能导致机密性、完整性和可用性的完全妥协。实际上，这种错误配置将平台的共享多用户设计变成了其最大的漏洞，暴露了整个混合 AI 管道以被接管。
早期阻断攻击链
红帽已发布修复此漏洞的补丁。然而，仅打补丁可能不够。
为了降低权限提升和完全集群接管的风险，组织应加强访问控制并持续监控滥用迹象。关键缓解措施包括：
- 加强 RBAC 控制：移除有问题的 ClusterRoleBinding，仅向受信任的组授予作业创建权限，并审计角色分配以强制执行最小权限原则。
- 监控异常活动：跟踪异常的 Pod 创建、服务账户升级和对 batch.kueue.openshift.io 的可疑 API 调用。
- 使用策略执行工具：部署准入控制器或 OPA/Kyverno 规则以阻止不受信任的 Pod 并防止权限滥用。
- 分段和保护工作负载：隔离命名空间、限制网络路径并轮换/限定范围的服务账户令牌以限制横向移动。
- 持续审计和测试：运行集群安全态势扫描、维护审计日志并为 Kubernetes/OpenShift 环境进行 IR 桌面演练。
虽然这些步骤降低了直接风险，但此次披露凸显了保护 AI 驱动的混合云环境中的更深层次挑战。
为何 AI 服务成为主要网络攻击目标
此次披露强调了企业面临的一个日益增长的挑战：由于 AI 服务在数据管道、知识产权保护和关键决策系统中的核心作用，它们正成为高价值目标。
OpenShift AI 漏洞说明了身份和访问管理中的单个错误配置如何升级为平台范围的泄露。
随着组织扩展混合云部署并采用 GenAI 服务，RBAC 强化和补丁纪律必须被视为与传统操作系统和应用程序补丁相同的紧迫性。攻击者越来越多地利用云原生平台，不是通过复杂的零日漏洞，而是通过过度宽松的默认设置和被忽视的权限绑定。
当一个错误配置可以推翻整个集群时，零信任不再是一种策略，而是一种必需。