Database/Container, Kubernetes & orchestration
Kite dashboard: any authenticated user can read cluster overview data for clusters they cannot access
Impact
The overview route is registered before Kite's RBAC middleware and GetOverview only checks that the caller has at least one role, so an authenticated user can set the x-cluster-name header to any cluster Kite fronts and receive its aggregate Kubernetes inventory and capacity data. The result is read-only disclosure across a boundary the dashboard is supposed to enforce. For an operator running one Kite instance over several clusters, this leaks node counts, capacity and workload inventory of production or other-customer clusters to anyone holding the lowest-privilege dashboard login, which is exactly the reconnaissance a later attack starts from. No write access and no credential disclosure is described.
Who can reach it
Any authenticated Kite user, regardless of role, sending a request to /api/v1/overview with the x-cluster-name header set to a cluster outside their permissions. Network reach to the dashboard plus a valid login is all that is needed.
What to do
Upgrade Kite to 0.12.3, which moves the route behind the RBAC middleware. This is a dashboard deployment upgrade: roll the Kite pod, no cluster or GPU node disruption. Until then, either run one Kite instance per trust boundary instead of one instance over many clusters, or block /api/v1/overview at the ingress or proxy in front of Kite. Treat any inventory data the dashboard exposed to low-privilege users as already disclosed.
References
Related entries
- Skipper: unbounded admission request body read lets a client OOM the proxy processCVE-2026-54247 · Skipper Kubernetes admission webhook (:9443/admission request body)Medium
- Dozzle: restricted users receive container stats and lifecycle events outside their label scopeCVE-2026-62286 · Dozzle (`/api/events/stream`, per-user label filter not applied to stat and event channels)Medium
- Cilium agent (network policy namespace label selectors): A tenant chooses which network policy applies to their ownNCVD-2022-004-cilium-agent-network-policy-name · Cilium agent (network policy namespace label selectors)Medium
- CRI-O: "Safe" sysctls applied to the host when a pod uses host IPC/networkCVE-2022-0532 · CRI-OMedium
- cosign / sigstore: Remote image with a malicious attachment DoSes the machine running cosignCVE-2024-29902 · cosign / sigstoreMedium
- cosign / sigstore: Crafted software artifacts DoS the cosign host, affecting all colocated servicesCVE-2024-29903 · cosign / sigstoreMedium
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.