Description

A flaw was found in the Red Hat OpenShift AI (RHOAI) overlay for the training operator. The RHOAI overlay incorrectly aggregates `trainjobs` management permissions into the native Kubernetes `edit ClusterRole`. This allows any user with `edit ClusterRole` permissions in a namespace to create, modify, and delete `TrainJobs`. When combined with a separate vulnerability (TRN-01) that permits arbitrary pod configurations, a remote attacker with namespace editor privileges could exploit this to escalate privileges, potentially leading to arbitrary code execution.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-10T21:17:21.710Z",
  "pubdate": "2026-08-10T21:17:21.710Z",
  "executiveSummary": "An authorization misconfiguration vulnerability exists in the Red Hat OpenShift AI (RHOAI) overlay for the training operator. The flaw involves the incorrect aggregation of trainjobs management permissions into the native Kubernetes edit ClusterRole. This improper permission aggregation allows any user or service account provisioned with namespace-scoped edit ClusterRole permissions to create, modify, and delete TrainJobs within their authorized namespace boundaries.\nThe primary impact of this vulnerability is privilege escalation within the Kubernetes cluster. When chained with a separate vulnerability designated as TRN-01, which permits arbitrary pod configurations, an authenticated remote attacker possessing namespace editor privileges can weaponize these aggregated permissions. This combination enables the attacker to deploy malicious workloads or manipulate existing training jobs, potentially leading to arbitrary code execution within the cluster environment.\nThe affected product is the Red Hat OpenShift AI (RHOAI) overlay for the training operator. Exploitation requires the attacker to already possess namespace editor privileges via the native Kubernetes edit ClusterRole and relies on the existence of the TRN-01 vulnerability regarding arbitrary pod configurations. Risk implications are significant for multi-tenant clusters where namespace isolation and role-based access control (RBAC) enforcement are critical security boundaries.",
  "technicalDetails": "The root cause of the vulnerability lies within the Kubernetes Role-Based Access Control (RBAC) configuration defined by the Red Hat OpenShift AI (RHOAI) overlay for the training operator. Specifically, the overlay incorrectly aggregates custom resource management permissions for TrainJobs into the native Kubernetes edit ClusterRole. By default, the edit ClusterRole is intended to grant read and write access to most resources within a namespace, excluding administrative roles and resource quotas. However, the improper inclusion of TrainJob permissions extends the operational capabilities of standard namespace editors beyond intended boundaries.\nThe vulnerable component is the RHOAI overlay configuration governing the training operator's custom resource definitions (CRDs) and associated ClusterRole aggregation rules. This misconfiguration lowers the barrier for privilege escalation by inadvertently trusting namespace-level editors with control over machine learning training infrastructure.\nThe authentication and privilege requirements necessitate that the actor already possesses valid credentials and namespace editor privileges corresponding to the native Kubernetes edit ClusterRole. Network exposure is constrained by the Kubernetes API server accessibility, assuming standard RBAC enforcement is active.\nThe attack flow proceeds in a multi-step sequence. First, an authenticated attacker with namespace editor privileges identifies that their assigned edit ClusterRole inadvertently grants permissions to manage TrainJobs due to the flawed RHOAI overlay configuration. Second, the attacker leverages the TRN-01 vulnerability, which allows for arbitrary pod configurations during job creation. Third, the attacker crafts a malicious TrainJob payload incorporating arbitrary pod specifications designed to mount sensitive volumes, execute malicious binaries, or escape container constraints. Fourth, the attacker submits the crafted TrainJob manifest to the Kubernetes API server within their accessible namespace. Finally, the training operator processes the malicious TrainJob, instantiating the attacker-controlled pods and resulting in arbitrary code execution and horizontal privilege escalation within the cluster environment."
}