OpenShift AI Trainer allowed job creators to mount Kubernetes Secrets they could not read

In Kubernetes, a human or service account may be allowed to create training-job resources but not read the Secrets held in its namespace. OpenShift AI Trainer v2 accepted environment variable references using valueFrom.secretKeyRef in a user-created TrainJob. The submitted workload could then obtain values from Secrets that the submitting identity could not itself retrieve through the Kubernetes API. The misbinding is between authorization to configure a workload and authorization to delegate the workload access to sensitive bytes.

Red Hat assigned CVE-2026-83495 to the issue. The publicly described preconditions require an affected deployment, TrainJob creation capability and namespace Secrets accessible to the created workload. The published record supports that capability escalation, not cross-namespace access or arbitrary cluster administrator privileges. The initial disclosure did not supply a fully checked fixed build or confirmed exploitation campaign.

AI training infrastructure using the affected Trainer v2 API in a namespace where job creators have weaker Secret permissions than their workloads can exercise.

The initial CVE data does not establish precise affected package builds, a confirmed vendor fix or any real credential theft. A namespace-constrained exposure must not be described as automatic cluster compromise.

An OpenShift AI namespace user may be authorized to create Trainer v2 TrainJob resources without having Kubernetes permission to retrieve Secrets. If admission accepts an arbitrary valueFrom.secretKeyRef in the job specification, Kubernetes can inject the named Secret into a workload that runs on behalf of the creator. That execution path grants the workload access the original user could not obtain through a direct Secret-read API call.

The authorization defect is therefore at job admission and credential materialization. It does not imply the user gained cluster administration, and it does not require a language model to choose the Secret. Preventive controls include a validating webhook binding permitted Secret references to the principal or workload service account, not just generic TrainJob creation permission. No independently validated vendor version boundary or real customer theft appears in the initial CVE record.