RED HAT OPENSHIFT AI (TRAINER V2, TECH PREVIEW) · CVE-2026-83495 · Infrastructure
NO FIX YET
Trainer v2 accepts valueFrom.secretKeyRef in TrainJob env definitions, so a TrainJob creator can read same-namespace Secrets beyond their RBAC. Red Hat mitigation: align TrainJob RBAC with Secret read RBAC, or restrict secretKeyRef in the validating webhook to an allowlist of secret names. No fixed version published yet.
first public Nov 7, 2026 · 2 sources
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Clusters running Kubeflow Trainer v2 (in Red Hat OpenShift AI it is a Technology Preview feature) where some users can create TrainJobs but are not allowed to read Secrets. Such a user can put valueFrom.secretKeyRef in a TrainJob's environment variables and read Secrets in the same namespace. Clusters without Trainer v2, or where TrainJob creators can already read Secrets, can skip it.
Not affected if no-trainer-v2, no-trainjob-creators-untrusted, secret-rbac-matches-trainjob-rbac, trainer-not-installed, trainjob-creators-can-read-secrets
Who cares kubeflow, kubernetes, openshift-ai, rbac, self-hosted, trainer-v2
Unknown from the sources.
A flaw was found in the Trainer v2 TrainJob API. A user with permissions to create TrainJobs can exploit this by injecting valueFrom.secretKeyRef into environment variable definitions. This allows them to read and exfiltrate sensitive information (secrets) from the namespace, leading to a privilege escalation. This occurs when the TrainJob Role-Based Access Control (RBAC) is broader than the Secret read RBAC.
This page as .md ·
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.