Vulnerability Database

363,159

Total vulnerabilities in the database

CVE-2026-53487 — github.com/zxh326/kite

Missing Authorization

Summary

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.

Impact

A low-privileged user who only has access to one cluster can set x-cluster-name to another configured cluster and retrieve aggregate inventory and resource sizing data for that cluster. The response includes total node, pod, namespace, service, CPU, and memory values. This bypasses the cluster membership boundary used elsewhere in Kite.

The validated impact is confidentiality only. I did not prove Kubernetes mutation, pod names, secret values, kubeconfig contents, or bearer token exposure through this endpoint.

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.

CVSS v3:

  • Severity: Low
  • Score: 4.3
  • AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

CWEs:

Software From Fixed in
Go icon github.com/zxh326/kite - 0.12.3

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.