CVE-2026-18982: RHOAI Training-Operator Privilege Escalation

CVE-2026-18982 Overview

CVE-2026-18982 is a privilege escalation flaw in the Red Hat OpenShift AI (RHOAI) training-operator. The vulnerability allows a user holding standard edit or admin roles in any Kubernetes namespace to escalate privileges cluster-wide. Attackers create training jobs to impersonate service accounts, mount the host filesystem, and execute arbitrary code on cluster nodes. The root defect lies in the aggregation of training job permissions onto native Kubernetes edit and admin ClusterRoles combined with unrestricted PodTemplateSpec passthrough. The weakness is classified as [CWE-250] Execution with Unnecessary Privileges.

Critical Impact
Any namespace user with edit or admin rights can pivot to cluster-level code execution and service account impersonation on RHOAI clusters.

Affected Products

Red Hat OpenShift AI (RHOAI) training-operator
Red Hat OpenShift AI distributions covered by RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263
Kubernetes clusters running the Kubeflow training-operator component as shipped with RHOAI

Discovery Timeline

2026-08-10 - CVE-2026-18982 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-18982

Vulnerability Analysis

The training-operator extends Kubernetes with custom resources such as PyTorchJob, TFJob, and MPIJob. When installed, its Role-Based Access Control (RBAC) manifests use aggregation labels that attach training job verbs to the built-in edit and admin ClusterRoles. Any user granted the standard namespace edit or admin binding therefore inherits the ability to create training resources without an administrator explicitly delegating that power.

Each training job embeds a PodTemplateSpec that the operator materializes into pods. The operator does not restrict fields such as serviceAccountName, hostPath volumes, hostPID, hostNetwork, or privileged security contexts. A namespace-scoped user can therefore request pods that bind to arbitrary service accounts in the same namespace, mount the underlying node filesystem, and run as root on the host.

Root Cause

The defect is a design-level RBAC and admission-control failure. Training job permissions are aggregated onto general-purpose ClusterRoles rather than gated behind a dedicated role, and the operator forwards user-supplied pod specifications to the Kubernetes API without validating sensitive fields.

Attack Vector

Exploitation requires an authenticated account with edit or admin rights in any namespace. The attacker submits a crafted training job whose worker PodTemplateSpec references a privileged service account and mounts / from the host. Once the pod is scheduled, the attacker executes commands as that service account and reads or writes files on the node, including kubelet credentials that permit lateral movement across the cluster.

No verified public exploit code is available. See the Red Hat CVE CVE-2026-18982 advisory for technical details.

Detection Methods for CVE-2026-18982

Indicators of Compromise

Training custom resources (PyTorchJob, TFJob, MPIJob, PaddleJob, XGBoostJob) submitted by non-administrator users with serviceAccountName fields pointing to privileged accounts.
Pods created by the training-operator that mount hostPath volumes referencing /, /etc, /var/lib/kubelet, or /var/run/docker.sock.
Training job pods running with hostPID: true, hostNetwork: true, or securityContext.privileged: true.

Detection Strategies

Audit Kubernetes API server logs for create verbs on training CRDs originating from users bound only to edit or admin ClusterRoles.
Deploy a policy engine such as Kyverno or OPA Gatekeeper to flag training resources whose pod templates reference host paths or non-default service accounts.
Correlate training-operator reconcile events with subsequent pod creations that violate namespace pod security standards.

Monitoring Recommendations

Enable Kubernetes audit logging at the RequestResponse level for kubeflow.org API groups and forward events to a central SIEM.
Alert on any pod created in an RHOAI-managed namespace that binds to a service account other than the submitting user's default account.
Track changes to the aggregated edit and admin ClusterRoles to detect reintroduction of training verbs after remediation.

How to Mitigate CVE-2026-18982

Immediate Actions Required

Apply the Red Hat updates delivered in RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263 to all affected RHOAI clusters.
Review existing RoleBinding and ClusterRoleBinding objects and revoke edit or admin rights from users who do not require training job access.
Inspect running training jobs for privileged pod specifications and terminate suspicious workloads.

Patch Information

Red Hat has issued fixes through the advisories RHSA-2026:53261, RHSA-2026:53262, and RHSA-2026:53263. Tracking details are available in the Red Hat Bug Report #2511648 and the Red Hat CVE page. Patched versions remove training verbs from the aggregated edit and admin ClusterRoles and validate PodTemplateSpec fields submitted through training CRDs.

Workarounds

Remove the aggregation labels from the training-operator ClusterRoles so training verbs no longer merge into edit and admin, then create a dedicated role for authorized data scientists.
Enforce Pod Security Admission at the restricted level on namespaces that host training jobs to block hostPath, hostPID, hostNetwork, and privileged containers.
Apply Kyverno or OPA Gatekeeper policies that reject training resources whose spec.template.spec.serviceAccountName differs from an allowlist.

bash

# Configuration example: Kyverno policy blocking host filesystem mounts in training jobs
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: block-training-hostpath
spec:
  validationFailureAction: Enforce
  rules:
    - name: no-hostpath-in-training-jobs
      match:
        any:
          - resources:
              kinds:
                - PyTorchJob
                - TFJob
                - MPIJob
      validate:
        message: "hostPath volumes are not permitted in training jobs."
        pattern:
          spec:
            =(pytorchReplicaSpecs):
              =(Worker):
                template:
                  spec:
                    =(volumes):
                      - X(hostPath): "null"