CVE-2026-18982 in OpenShift AI
Summary
by MITRE • 08/11/2026
A flaw was found in the RHOAI training-operator. This vulnerability allows a user with standard edit or admin roles in any Kubernetes namespace to escalate their privileges. Through the creation of training jobs, an attacker can impersonate service accounts, access the host filesystem, and potentially execute arbitrary code remotely. This issue arises from the aggregation of training job permissions onto native Kubernetes edit and admin ClusterRoles, coupled with unrestricted PodTemplateSpec passthrough.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/11/2026
This vulnerability exists within the RHOAI training-operator component where a privilege escalation flaw allows users with standard edit or admin roles in any Kubernetes namespace to gain elevated access. The weakness stems from how the operator handles training job creation permissions, specifically through the aggregation of training job capabilities onto existing native Kubernetes ClusterRoles that include edit and admin privileges. This design flaw enables attackers to leverage their existing permissions to perform unauthorized actions beyond their intended scope.
The technical implementation of this vulnerability exploits the unrestricted passthrough of PodTemplateSpec elements within training jobs, which creates opportunities for service account impersonation. When users create training jobs, the operator does not properly validate or sanitize the Pod specifications, allowing malicious actors to inject privileged containers or modify existing ones. This occurs because the system assumes that legitimate users with edit or admin roles can safely create such job templates without additional security checks.
The operational impact of this vulnerability is significant as it enables attackers to access the host filesystem through the impersonated service accounts, potentially leading to complete cluster compromise. An attacker could execute arbitrary code remotely by leveraging these elevated privileges to gain access to sensitive data, modify critical system components, or establish persistent backdoors within the Kubernetes environment. The vulnerability essentially transforms standard user permissions into full cluster administrative capabilities.
From a cybersecurity perspective, this issue aligns with CWE-269 Privilege Management and CWE-78 Improper Neutralization of Special Elements used in OS Command, as it involves improper handling of privileges and unvalidated inputs. The attack vector follows ATT&CK techniques such as T1078 Valid Accounts for initial access and T1565 Data Manipulation for potential data compromise. Organizations should implement strict validation of PodTemplateSpec elements in training jobs, enforce least privilege principles for role assignments, and regularly audit ClusterRole permissions to prevent unauthorized escalation.
Mitigation strategies include implementing proper input validation and sanitization for all user-supplied Pod specifications, restricting the aggregation of permissions onto existing ClusterRoles, and deploying automated monitoring solutions to detect suspicious training job creation patterns. Security teams should also consider implementing admission controllers that validate training job configurations against security policies, and regularly audit namespace-level permissions to ensure they align with principle of least privilege. The solution requires comprehensive policy enforcement rather than reactive measures, as the vulnerability allows attackers to exploit existing legitimate user accounts for unauthorized access.
This vulnerability demonstrates the importance of proper privilege separation in containerized environments and highlights how seemingly innocuous features can create security risks when not properly validated. Organizations deploying RHOAI or similar platforms should immediately review their current configurations and implement the recommended mitigations to prevent potential exploitation by threat actors who may attempt to leverage these permissions for unauthorized access to Kubernetes clusters.