GHSA-gvhc-wv3v-7pf8: Kite has an authenticated cluster RBAC bypass in /api/v1/overview
An authenticated user of Kite with any role can bypass cluster RBAC controls on the /api/v1/overview endpoint by specifying a different cluster name via the x-cluster-name header. This allows retrieval of aggregate Kubernetes inventory and capacity data for clusters the user is not authorized to access. The vulnerability affects Kite versions prior to 0.12.3. The impact is limited to confidentiality, exposing aggregate resource data but not sensitive details like pod names or secrets.
AI Analysis
Technical Summary
Kite's /api/v1/overview route is registered before the global RBAC middleware is applied, and its handler only checks that the user has at least one role, not whether the user is authorized for the requested cluster. By setting the x-cluster-name header to a cluster the user is unauthorized for, an authenticated user can retrieve aggregate data such as total nodes, pods, namespaces, services, and resource usage for that cluster. The intended cluster access checks are implemented elsewhere but are skipped for this endpoint. This issue is present in Kite main branch commit 38c9bb9d4b746c0d2a8252f3c35cdfa07ab01c21 and release v0.12.2, and is fixed in versions 0.12.3 and later.
Potential Impact
An authenticated user with limited cluster access can bypass cluster membership boundaries to obtain aggregate inventory and capacity data for unauthorized clusters. This exposure is limited to confidentiality of aggregate resource metrics and does not include sensitive information such as pod names, secrets, kubeconfig contents, or bearer tokens. There is no impact on integrity or availability.
Mitigation Recommendations
Patch to version 0.12.3 or later where this issue is fixed. The recommended fix is to add explicit cluster and resource authorization checks before querying overview data, rejecting users without rbac.CanAccessCluster(user, clusterName). Additionally, ensure that all routes requiring authorization are registered after the global RBAC middleware or have per-handler authorization checks. Until patched, restrict access to trusted users and monitor usage of the /api/v1/overview endpoint for anomalous cluster access patterns.
GHSA-gvhc-wv3v-7pf8: Kite has an authenticated cluster RBAC bypass in /api/v1/overview
Description
An authenticated user of Kite with any role can bypass cluster RBAC controls on the /api/v1/overview endpoint by specifying a different cluster name via the x-cluster-name header. This allows retrieval of aggregate Kubernetes inventory and capacity data for clusters the user is not authorized to access. The vulnerability affects Kite versions prior to 0.12.3. The impact is limited to confidentiality, exposing aggregate resource data but not sensitive details like pod names or secrets.
CVSS v3.1
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Kite's /api/v1/overview route is registered before the global RBAC middleware is applied, and its handler only checks that the user has at least one role, not whether the user is authorized for the requested cluster. By setting the x-cluster-name header to a cluster the user is unauthorized for, an authenticated user can retrieve aggregate data such as total nodes, pods, namespaces, services, and resource usage for that cluster. The intended cluster access checks are implemented elsewhere but are skipped for this endpoint. This issue is present in Kite main branch commit 38c9bb9d4b746c0d2a8252f3c35cdfa07ab01c21 and release v0.12.2, and is fixed in versions 0.12.3 and later.
Potential Impact
An authenticated user with limited cluster access can bypass cluster membership boundaries to obtain aggregate inventory and capacity data for unauthorized clusters. This exposure is limited to confidentiality of aggregate resource metrics and does not include sensitive information such as pod names, secrets, kubeconfig contents, or bearer tokens. There is no impact on integrity or availability.
Mitigation Recommendations
Patch to version 0.12.3 or later where this issue is fixed. The recommended fix is to add explicit cluster and resource authorization checks before querying overview data, rejecting users without rbac.CanAccessCluster(user, clusterName). Additionally, ensure that all routes requiring authorization are registered after the global RBAC middleware or have per-handler authorization checks. Until patched, restrict access to trusted users and monitor usage of the /api/v1/overview endpoint for anomalous cluster access patterns.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-gvhc-wv3v-7pf8
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-53487"]
- Ecosystems
- ["Go"]
- Database Specific Severity
- MODERATE
- Cvss Version
- 3.1
Threat ID: 6a4e4ee7c9d9e3dbe3289b5d
Added to database: 07/08/2026, 13:21:43 UTC
Last enriched: 07/08/2026, 13:40:55 UTC
Last updated: 07/09/2026, 00:50:40 UTC
Views: 4
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.