Bug 2511187 (CVE-2026-18951)

Summary: CVE-2026-18951 odh-training-operator-rhel9: [Trainer v2 Security] TRN-02: RHOAI overlay aggregates trainjobs CRUD into standard edit ClusterRole
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: unspecifiedCC: security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-04 19:06:48 UTC 
Description

Finding: TRN-02
Severity: High | Priority: Critical | Embargo: Embargoed

Source: Security audit HCMSEC-3528 — red-hat-data-services/trainer

Summary
The RHOAI overlay aggregates trainjobs CRUD (create, read, update, delete) into the native Kubernetes edit ClusterRole. This means every namespace editor — not just users with explicit trainjobs RBAC — can create, modify, and delete TrainJobs. Combined with TRN-01 (PodSpec passthrough), this widens the confused-deputy attack surface to all namespace editors.

Risk
Amplified attack surface: TRN-01's privilege escalation (SA hijack, hostPath, tolerations) becomes available to every user with the edit ClusterRole in any namespace, not just users explicitly granted trainjobs permissions

Implicit permission grant: Users who were granted edit for standard Kubernetes resource management (Deployments, Services, ConfigMaps) now implicitly receive the ability to create training workloads with arbitrary pod configurations

No visibility: Namespace admins may not realize that granting edit also grants training job creation with its associated security implications

Root Cause
Fork-introduced: this RBAC aggregation is specific to the RHOAI overlay and does not exist in upstream Kubeflow trainer.

Recommendation
Remove trainjobs from the aggregate-to-edit ClusterRole labels

Require explicit RoleBinding for trainjobs access — users should opt-in to training job creation

If aggregation is required for UX reasons, aggregate to a custom training-user role that is not the native edit role

Document that trainjobs access carries security implications beyond standard resource management

Related Non-Embargoed Findings
RHOAIENG-69132 — TRN-06: Webhook structural-only validation (root enabler of TRN-01)

RHOAIENG-69130 — TRN-03: TrainingRuntime/ClusterTrainingRuntime aggregated to admin

RHOAIENG-69136 — TRN-09: ClusterTrainingRuntime correctly NOT aggregated to edit (positive contrast)

Context
Trainer v2 is Technology Preview (not GA) as of RHOAI 3.4

Fork-introduced: same pattern as training-operator v1 (TO-01)

Embargo applies even for Technology Preview per prodsec guidance