My Take on CVE-2025-10725 (Red Hat OpenShift AI)
Have you heard about the CVE-2025-10725 already? If not, let me walk you through.
This vulnerability was recently found in the Red Hat OpenShift AI product. This is about overly permissive role configuration that could allow any authenticated user to escalate their privileges to a full cluster administrator. It’s rated as 9.9, and I want to share some context on the finding.
The root of the issue
A specific ClusterRole, kueue-batch-user-role, was incorrectly bound to the system:authenticated group. This configuration granted any authenticated entity (from a standard user to a service account) the permission to create OpenShift Jobs in any namespace across the entire cluster.
The risk here is that an attacker could abuse this permission to schedule a malicious Job in a highly privileged namespace. By configuring the Job to run with that namespace's powerful ServiceAccount, an attacker could exfiltrate its token and ultimately gain full control of the cluster.
The Solution: Don't Wait, Update
The good news is that a solution is available and straightforward. The engineering teams have already released the necessary patches. In response to the finding, the engineering teams acted immediately, developing and releasing the necessary patches in record time to ensure the platform's security.
The most important action is to stop reading the article and upgrade now. Don’t let a desire for a "perfect" patching window lead to delays. When a solution is available, the answer is to implement it.
Below are the recommended mitigation steps for affected versions.
For RHOAI versions 2.16.x
The recommended fix is to upgrade to version 2.16.3.
Alternatively, if you do not require Kueue features, you can set the Kueue component management state to Removed with the following command:
oc patch dsc default-dsc \
--type=merge \
-p='{"spec":{"components":{"kueue":{"managementState":"Removed"}}}}' \
-n redhat-ods-operatorFor RHOAI versions 2.19 and newer
The recommended fix is to apply the applicable security errata.
Alternatively, you can manually mitigate the issue with the following steps:
- Disable the ClusterRoleBinding. Update its subject to a different, non-existent group to effectively disable it:
oc patch clusterrolebinding kueue-batch-user-rolebinding \
-p '{
"subjects": [
{
"kind": "Group",
"name": "<--REPLACE-ME-->",
"apiGroup": "rbac.authorization.k8s.io"
}
]
}'- Prevent the RHOAI operator from managing the role binding. Apply the necessary annotation with this command:
oc patch clusterrolebinding kueue-batch-user-rolebinding \
-p '{"metadata":{"annotations": {"opendatahub.io/managed":"false"}}}'
Q&A
Q: In the mitigation for 2.19+, does the group have to be non-existent? What's the risk of using an existing group?
A: Yes, using a non-existent group is a critical part of the mitigation. If you were to use an existing group, you might unintentionally grant those users cluster-wide job execution permissions, which is the exact risk this mitigation is designed to prevent.
Q: Do these manual mitigation steps impact future upgrades?
A: No. Applying these mitigation steps will not impact your ability to upgrade your platform in the future.
Acknowledge
This issue was identified internally by Red Hat's own security team members: Jon Weiser, Raul Bringas, and Oleg Sushchenko. This is a great example of a proactive security process and the capture, reuse, and improve principle in action.
Don't know what that is? I've got you covered. You can read about it here.
References
This article is a summary of the information found in the following official sources. For a deeper dive, please visit the links themselves:
Member discussion