A high-severity vulnerability in Red Hat OpenShift AI’s dashboard component exposes Kubernetes Service Account tokens to unauthenticated attackers, potentially enabling full cluster compromise. CVE-2026-5483, disclosed on April 10, 2026, carries a CVSS score of 8.5 and affects the odh-dashboard component — the web UI that data scientists and ML engineers use daily to manage notebooks, model serving, and data science pipelines on OpenShift.

What Happened

Red Hat published security advisories (RHSA-2026:7404, RHSA-2026:7403, RHSA-2026:7398, RHSA-2026:7397) for a vulnerability in the Open Data Hub dashboard, the frontend component of OpenShift AI. A NodeJS endpoint in odh-dashboard improperly handles requests in a way that discloses Kubernetes Service Account tokens to callers.

The flaw is classified under CWE-201 (Insertion of Sensitive Information Into Sent Data). This isn’t an injection bug or a logic error in authentication — it’s the dashboard’s backend directly leaking credentials that should never leave the server process.

Technical Details

The vulnerability exists in a NodeJS API endpoint within odh-dashboard that returns Kubernetes Service Account token data in its response. Service Account tokens in Kubernetes are bearer tokens — anyone who possesses one can authenticate to the Kubernetes API server with the privileges bound to that account.

In a typical OpenShift AI deployment, the dashboard’s Service Account has broad permissions across the namespace (and potentially across the cluster, depending on how RBAC is configured). These permissions often include the ability to:

  • Create, modify, and delete notebook servers and model serving instances
  • Access secrets containing model registry credentials, S3 keys, and database connection strings
  • Interact with pipelines that may have elevated cluster-wide roles
  • Read ConfigMaps and Secrets in the OpenShift AI namespace

The attack surface is significant because odh-dashboard is a web-facing service. If it’s exposed outside the cluster — which is the default in most OpenShift deployments via Routes — the endpoint is reachable from the network without any prior authentication.

Impact Assessment

Organizations running Red Hat OpenShift AI are the primary targets. This includes enterprises using OpenShift for ML/AI workloads, which typically means the cluster holds sensitive training data, model artifacts, and credentials for external services (cloud storage, databases, GPU providers).

The severity depends on the RBAC configuration of the compromised Service Account:

  • Best case: The token grants namespace-scoped read access, limiting the attacker to information disclosure within the OpenShift AI namespace.
  • Worst case: The Service Account has cluster-admin or broadly-scoped ClusterRole bindings, giving the attacker full control over the Kubernetes cluster, including the ability to deploy workloads, exfiltrate secrets, and pivot to other namespaces.

Many OpenShift AI deployments fall closer to the worst case because the dashboard needs elevated permissions to manage resources across the platform.

Mitigation Steps

Immediate actions:

  1. Apply Red Hat’s patches. Update odh-dashboard to the fixed version referenced in the RHSA advisories. If you’re running OpenShift AI via an operator, trigger an operator update.

  2. Audit Service Account RBAC. Check what permissions the odh-dashboard Service Account holds. Run oc get clusterrolebindings,rolebindings -A -o json | jq '.items[] | select(.subjects[]?.name == "odh-dashboard")' to see all bindings.

  3. Restrict network access. If the dashboard Route is exposed to the public internet, restrict it to internal networks or add authentication at the ingress layer (OAuth proxy, network policy) while patching.

  4. Rotate tokens. After patching, delete and recreate the Service Account to invalidate any tokens that may have been leaked: oc delete sa odh-dashboard -n <namespace> (the operator will recreate it with a fresh token).

  5. Check audit logs. Review Kubernetes API server audit logs for unusual activity from the odh-dashboard Service Account, especially requests originating from unexpected source IPs.

Longer-term hardening:

  • Apply the principle of least privilege to all AI/ML platform Service Accounts. The dashboard should not need cluster-admin.
  • Enable bound Service Account tokens (audience and time-bound) rather than long-lived static tokens.
  • Deploy network policies that restrict egress from the dashboard pod to only the Kubernetes API server and required backend services.

References