CVE-2026-53487
vulnerability analysis and mitigation

Overview

CVE-2026-53487 is an authenticated cluster RBAC bypass vulnerability in Kite, a Kubernetes management tool, affecting all versions up to and including v0.12.2. The flaw allows any authenticated Kite user with at least one role to access the /api/v1/overview endpoint for clusters they are not authorized to view by supplying an arbitrary cluster name via the x-cluster-name header. It was first published by the reporter (DavidCarliez) on May 31, 2026, and added to the GitHub Advisory Database on July 7, 2026. The vulnerability carries a CVSS v3.1 base score of 4.3 (Medium) (GitHub Advisory, Kite Advisory).

Technical details

The root cause is a missing authorization check (CWE-862) caused by a route registration ordering error in routes.go. The /api/v1/overview route is registered at line 135 before the global middleware.RBACMiddleware() is applied at line 171, meaning the RBAC middleware never executes for this endpoint. The ClusterMiddleware in pkg/middleware/cluster.go accepts the target cluster name from the x-cluster-name header, query parameter, or cookie and injects the corresponding ClientSet without verifying whether the requesting user has permission to access that cluster. The GetOverview handler in pkg/system/handler.go only checks len(user.Roles) > 0 — rejecting users with zero roles — but does not call rbac.CanAccessCluster(user, cs.Name), which is the check correctly used by the /api/v1/clusters endpoint. A Go proof-of-concept test (TestOverviewAllowsUserWithoutTargetClusterRBAC) was developed and confirmed the bypass (GitHub Advisory, Kite Advisory).

Impact

The impact is limited to confidentiality. A low-privileged authenticated user can retrieve aggregate Kubernetes inventory and resource sizing data — including total node count, pod count, namespace count, service count, and CPU/memory allocations — for any cluster configured in the Kite instance, regardless of their assigned cluster permissions. The advisory explicitly states that Kubernetes mutation, individual pod names, secret values, kubeconfig contents, and bearer tokens are not exposed through this endpoint. In multi-tenant or multi-environment Kite deployments (e.g., separate dev and prod clusters), this could allow an attacker to enumerate the scale and resource posture of production infrastructure they should not have visibility into (GitHub Advisory).

Exploitation steps

  1. Authenticate: Log in to the target Kite instance as any user with at least one assigned role (even a low-privileged role scoped to a single cluster such as dev-cluster).
  2. Enumerate clusters: Optionally, use the /api/v1/clusters endpoint to list clusters visible to your account, or guess/enumerate cluster names from naming conventions.
  3. Craft the request: Construct a GET /api/v1/overview HTTP request and add the header x-cluster-name: <target-cluster> (e.g., x-cluster-name: prod-cluster) where <target-cluster> is a cluster the authenticated user is not authorized to access.
  4. Send the request: Submit the request to the Kite API. Because the route is registered before RBACMiddleware() and the handler only checks for a non-empty roles list, the server processes the request without performing a cluster authorization check.
  5. Retrieve unauthorized data: The response returns a JSON object containing aggregate inventory data for the unauthorized cluster, including totalNodes, totalPods, totalNamespaces, totalServices, and CPU/memory resource values (GitHub Advisory, Kite Advisory).

Indicators of compromise

  • Network: HTTP GET requests to /api/v1/overview from authenticated users with an x-cluster-name header value that does not match any cluster in their assigned roles.
  • Logs: Kite access logs showing repeated or anomalous GET /api/v1/overview requests from a single user account targeting multiple different cluster names in a short time window, particularly cluster names outside the user's normal scope.
  • Behavioral: A user account with a role scoped to one cluster (e.g., dev-cluster) making successful 200 OK requests to /api/v1/overview with x-cluster-name set to other clusters (e.g., prod-cluster, staging-cluster).

Mitigation and workarounds

Upgrade to Kite v0.12.3, which is the patched release that addresses this vulnerability. The recommended fix is to add an explicit rbac.CanAccessCluster(user, cs.Name) check in the GetOverview handler before any cluster data is queried, and to move all routes lacking complete per-handler authorization to be registered after api.Use(middleware.RBACMiddleware()) in routes.go. As a temporary workaround where upgrading is not immediately possible, restrict Kite access to trusted users only and audit role assignments to minimize the number of users with any assigned role. Adding per-handler authorization tests for all pre-RBAC routes is also recommended to prevent similar issues in the future (GitHub Advisory, Kite Advisory).

Additional resources


SourceThis report was generated using AI

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management