OpenShift AI training-operator: namespace edit/admin users escalate to host filesystem access via crafted training jobs

Impact

The training-operator aggregates training-job permissions onto the native Kubernetes edit and admin ClusterRoles and passes the submitted PodTemplateSpec through unrestricted. A user with ordinary edit or admin rights in any namespace can therefore create a training job whose pod spec impersonates service accounts, mounts the host filesystem, and runs code with those privileges. On a GPU cluster this is exactly the population you expect to be untrusted-ish - data scientists with edit rights in their own project namespace - and the pods they submit land on GPU nodes. Host filesystem access on a GPU node reaches the kubelet credentials, other tenants' container roots and the node's device state, and evicting the attacker means draining a node that is expensive to take out of service.

Who can reach it

Any authenticated cluster user holding the standard edit or admin role in a single namespace. No cluster-admin, no node access, and no separate training-operator permission grant is required.

What to do

Apply the Red Hat errata for your OpenShift AI stream (RHSA-2026:53261/53262/53263 for 2.25/3.3/3.4, RHSA-2026:60520); the operator upgrade restarts the training-operator controller and tightens the RBAC aggregation. Until then, review who holds edit/admin in project namespaces and add admission policy (Pod Security admission or a validating policy) that rejects hostPath mounts, host namespaces and arbitrary serviceAccountName in training-job pod templates. Any node that ran an untrusted job during the exposure window should be treated as suspect and drained before reuse.

References

Related entries

• vLLM (HF `auto_map`): Loads Hugging Face dynamic modules during model resolutionCVE-2026-22807 · vLLM (HF `auto_map`)High
• PyTorch (`weights_only` unpickler): Bypass of the `weights_only` allowlistCVE-2026-24747 · PyTorch (`weights_only` unpickler)High
• vLLM (hardcoded `trust_remote_code`, second instance): Same class, two more model files, through 0.18.0CVE-2026-27893 · vLLM (hardcoded `trust_remote_code`, second instance)High
• JupyterHub OAuthenticator: Authenticated user bypasses the intended identity checkCVE-2026-33175 · JupyterHub OAuthenticatorHigh
• LiteLLM (`/config/update`): Endpoint does not enforce admin authorizationCVE-2026-35029 · LiteLLM (`/config/update`)High
• BentoML (Dockerfile generation): Injection into generated DockerfileCVE-2026-35044 · BentoML (Dockerfile generation)High