Description

A flaw was found in odh-dashboard. An authenticated user of the dashboard can exploit a vulnerability related to how RoleBindings are created. The system does not properly validate the `roleRef` field, allowing a user to specify an arbitrary role, including highly privileged ones like `cluster-admin`. This can lead to privilege escalation, where an attacker gains unauthorized elevated access within their namespace and potentially persistent control over the system.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-10T21:17:21.583Z",
  "pubdate": "2026-08-10T21:17:21.583Z",
  "executiveSummary": "A privilege escalation vulnerability has been identified in odh-dashboard, specifically related to the creation and handling of RoleBindings.\nThe vulnerability allows an authenticated user to exploit inadequate input validation within the roleRef field during RoleBinding creation.\nBy supplying an arbitrary role within the roleRef parameter, an attacker can successfully bind highly privileged roles, such as cluster-admin, to their security context within a target namespace.\nThe impact of this flaw includes unauthorized elevation of privileges, potential persistent control over the affected system, and unauthorized access to sensitive cluster resources.\nExploitation of this vulnerability requires prior authentication to the odh-dashboard, granting the attacker the baseline capability to interact with authorization and role-binding mechanisms.\nThe risk implication is severe, as it undermines namespace isolation and access control boundaries, potentially compromising the entire orchestration layer depending on the scope of the abused role references.",
  "technicalDetails": "The root cause of the vulnerability resides in the backend logic of odh-dashboard responsible for processing API requests to instantiate RoleBindings. Specifically, the application fails to perform rigorous input validation and sanitization on the roleRef field.\nThe roleRef field in Kubernetes RoleBinding and ClusterRoleBinding objects designates the specific Role or ClusterRole being assigned to a subject. Because the dashboard component does not enforce an allowlist or properly validate the target role against the permissions held by the creator or permissible tenant boundaries, an attacker can reference arbitrary roles.\nTo execute the attack, an authenticated user initiates an HTTP request to the odh-dashboard API endpoint responsible for creating RoleBindings. Within the JSON payload of the request, the user crafts a custom roleRef object referencing a highly privileged role, such as cluster-admin or equivalent cluster-scoped administrative roles.\nUpon receiving the request, the vulnerable component processes and submits the API call to the underlying Kubernetes API server without adequately verifying whether the requesting user possesses the authorization to delegate such elevated permissions, or if the referenced role is appropriate for the user's operational scope.\nOnce the malicious RoleBinding is successfully created within the targeted namespace, the attacker's associated service account or user identity immediately inherits the permissions granted by the referenced role.\nThe attack flow demonstrates a classic broken access control and authorization enforcement failure at the application wrapper level, bypassing intended tenancy restrictions and leveraging the permissions of the underlying service account executing the dashboard logic.\nPost-exploitation impact includes full administrative control over the affected namespace, capability to read secrets, manipulate workloads, and potentially leverage misconfigured cluster-scoped roles to achieve broader persistence or lateral movement across the infrastructure."
}