Database/AI/ML frameworks & serving
OpenShift AI dashboard: incorrect network binding lets an in-cluster actor impersonate any user with an arbitrary token
Impact
Because of an incorrect network binding in odh-dashboard, an actor already inside the cluster can bypass the dashboard's authentication and impersonate any user by supplying an arbitrary access token. The dashboard talks to the Kubernetes API on the user's behalf, so impersonating a privileged user yields that user's API access - Red Hat describes arbitrary code execution, privilege escalation and information disclosure as possible outcomes. On an OpenShift AI cluster this is the front door to the GPU estate: notebook workbenches, model-serving runtimes, data connections and the accelerator profiles that decide who gets which GPUs. Any pod a tenant can run is a viable launch point, so the blast radius covers other tenants' notebooks and models.
Who can reach it
A malicious actor with network reach inside the cluster - any workload or pod that can connect to the odh-dashboard service. Authentication to the dashboard is not needed; the attacker supplies a token of their choosing.
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) and let the operator roll the dashboard deployment - a pod restart of the console component, not a node drain, so GPU workloads keep running. Until patched, restrict network policy so only the ingress/route path can reach the odh-dashboard service rather than arbitrary in-cluster pods.
References
Related entries
- OpenShift AI training-operator: namespace edit/admin users escalate to host filesystem access via crafted training jobsCVE-2026-18982 · Red Hat OpenShift AI training-operator (ClusterRole aggregation + PodTemplateSpec passthrough)High
- 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
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.