Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Kite versions 0.6.9 through 0.14.0 authorize Kubernetes proxy requests against the pod or service identified by the original route parameters. Encoded path traversal segments can cause the upstream URL to resolve to a different Kubernetes API endpoint after authorization. Impact An authenticated user with get permission on pods or services in one namespace can cause Kite to issue GET requests to Kubernetes API endpoints outside that namespace using Kite's service account. With Kite's default Helm RBAC configuration, this allows cluster-wide resource disclosure, including Secrets. The validated impact is confidentiality only; resource modification and denial of service were not demonstrated. Deployments using a restricted Kite service account are affected only up to the permissions granted to that service account. Technical details The authorization check is performed against the original namespace and kind route parameters. The proxy path is subsequently decoded and passed to…
Recommended action: Upgrade to 0.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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,…
Recommended action: Upgrade to 0.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.