CVE-2026-53487

Authenticated Kite users with any role can request /api/v1/overview for a cluster that their roles do not permit by selecting that cluster with x-cluster-name. The overview route is registered before middleware.RBACMiddleware() and GetOverview only checks len(user.Roles) > 0, so it returns aggregate Kubernetes inventory and capacity data from unauthorized clusters.

The issue is present on current main commit 38c9bb9d4b746c0d2a8252f3c35cdfa07ab01c21 and latest release v0.12.2 at commit 0aae35abb2d6a8adf623fe60349261aa48753ccc.

Technical details

routes.go registers /api/v1/overview before the global RBAC middleware is applied:

• routes.go:131-133: /api/v1 gets RequireAuth() and ClusterMiddleware(cm).
• routes.go:135: /api/v1/overview is registered.
• routes.go:171: api.Use(middleware.RBACMiddleware()) is applied only after overview and several other routes are registered.

pkg/middleware/cluster.go:21-40 accepts the target cluster name from x-cluster-name, query, or cookie and injects the matching ClientSet without checking whether the user can access that cluster.

pkg/system/handler.go:47-52 retrieves the selected cluster and user, but only rejects users with zero roles:

cs := c.MustGet("cluster").(*cluster.ClientSet)
user := c.MustGet("user").(model.User)
if len(user.Roles) == 0 {
    c.JSON(http.StatusForbidden, gin.H{"error": "Access denied"})
    return
}

It then lists nodes, pods, namespaces, and services for the selected cluster at pkg/system/handler.go:63-137 and returns aggregate data at pkg/system/handler.go:147-169.

The intended cluster boundary exists elsewhere. pkg/cluster/cluster_handler.go:19-47 filters /api/v1/clusters with rbac.CanAccessCluster(user, name), and pkg/rbac/rbac.go:32-40 implements that cluster check. The vulnerable overview path skips the same check.

Reproduction

1. Configure Kite with at least two clusters, for example dev-cluster and prod-cluster.
2. Create a user with a role that allows only dev-cluster and does not match prod-cluster.
3. Authenticate as that user.
4. Send GET /api/v1/overview with header x-cluster-name: prod-cluster.
5. Observe that the response includes aggregate inventory and capacity data for prod-cluster instead of returning 403.

I also validated this locally with a Go proof test. The test constructs a fake prod-cluster containing one node, namespace, service, and pod. The user has a role limited to dev-cluster and dev-ns only. Before calling the handler, both controls return false:

• rbac.CanAccess(user, "pods", "get", "prod-cluster", "_all")
• rbac.CanAccessCluster(user, "prod-cluster")

The direct handler call then succeeds and returns the unauthorized production cluster aggregate data.

Command run:

cd /home/unkn0wn/security_audit/kite
go test ./pkg/system -run TestOverviewAllowsUserWithoutTargetClusterRBAC -v

Key output:

=== RUN   TestOverviewAllowsUserWithoutTargetClusterRBAC
    overview_rbac_poc_test.go:74: unauthorized overview response: {"totalNodes":1,"readyNodes":0,"totalPods":1,"runningPods":0,"totalNamespaces":1,"totalServices":1,"prometheusEnabled":false,"resource":{"cpu":{"allocatable":0,"requested":0,"limited":0},"memory":{"allocatable":0,"requested":0,"limited":0}}}
--- PASS: TestOverviewAllowsUserWithoutTargetClusterRBAC (0.49s)
PASS
ok  	github.com/zxh326/kite/pkg/system	0.711s

Suggested remediation

Add an explicit cluster and resource authorization check before any overview data is queried. At minimum, reject users without rbac.CanAccessCluster(user, cs.Name). A stricter fix should require the same resource permissions used by the AI get_cluster_overview tool:

• get nodes at cluster scope
• get pods across all namespaces
• get namespaces at cluster scope
• get services across all namespaces

Also consider moving every route that lacks its own complete authorization below api.Use(middleware.RBACMiddleware()), or adding per-handler authorization tests for all pre-RBAC routes.