al-ice.ai

Red Hat OpenShift AI — Kubernetes Token Disclosure (CVE-2026-5483)

Security / AI CVEs by al-ice.ai Editorial

Red Hat OpenShift AI — Kubernetes Token Disclosure (CVE-2026-5483)

AI relevance: Red Hat OpenShift AI (RHOAI) is Red Hat's enterprise AI/ML platform — a leaked Kubernetes service account token from its dashboard gives attackers direct access to the cluster running AI workloads, models, and training pipelines.

  • CVE-2026-5483 carries a CVSS score of 8.5 (High) and affects the odh-dashboard component of Red Hat OpenShift AI
  • A NodeJS endpoint within the dashboard discloses Kubernetes Service Account tokens to unauthorized parties
  • The vulnerability is network-accessible with low attack complexity — no authentication required to trigger token disclosure
  • Disclosed tokens can be used to authenticate to the Kubernetes API, granting unauthorized access to cluster resources
  • OpenShift AI manages AI/ML workloads, model serving, Jupyter notebooks, and data science pipelines — cluster access puts all of these at risk
  • This is part of a broader pattern of AI platform infrastructure vulnerabilities — similar to the Azure MCP auth bypass (CVE-2026-32211) and SRE Agent info disclosure (CVE-2026-32173) from Microsoft's April 2026 Patch Tuesday
  • No public proof-of-concept available at time of writing; no patch details published in the advisory

Why It Matters

AI platforms like OpenShift AI run on Kubernetes with elevated service account permissions for model deployment, GPU scheduling, and data pipeline orchestration. A service account token leak from the dashboard — the administrative UI — is particularly dangerous because these tokens typically have broad cluster-scoped permissions. Attackers who obtain these tokens can deploy malicious workloads, exfiltrate training data, or pivot to other services in the cluster.

What To Do

  • Identify the vulnerable endpoint — audit odh-dashboard NodeJS routes for any that return service account tokens without proper auth checks
  • Restrict network access to the dashboard — ensure odh-dashboard is not exposed to untrusted networks; use network policies
  • Rotate service account tokens — if you're running affected versions, assume tokens may have been exposed and rotate them
  • Apply least-privilege RBAC — limit what the dashboard's service account can do in the cluster
  • Monitor Kubernetes API access logs — watch for authentication using unexpected service account tokens or from unusual source IPs

Sources: