KubePi: authenticated cluster manager can read and modify clusters outside their granted scope

Impact

KubePi is a multi-cluster panel that holds admin kubeconfigs for every cluster it manages, so its per-cluster scoping is the only thing separating one team's cluster from another's. Cluster-scoped endpoints do not consistently check that the caller is authorized for the specific cluster named in the request, so a user granted management rights on one cluster can read or modify objects in clusters they were never given. The vendor's scoring rates the impact on the subsequent system - the target Kubernetes cluster - as high for confidentiality, integrity and availability, which is what an operator would expect when panel-held credentials are used out of scope. On a shared GPU estate where separate clusters are the tenancy boundary, this collapses that boundary at the management layer rather than at the node.

Who can reach it

Any authenticated KubePi user who already holds cluster management permissions on at least one cluster, reaching the KubePi web API over the network. Exploitability depends on the role and cluster configuration in use.

What to do

Upgrade KubePi to 2.0.1 and redeploy the panel container. Because KubePi holds cluster credentials, also review audit logs on managed clusters for actions attributed to the KubePi service account that did not originate from an authorized operator, and rotate any kubeconfig you cannot account for.

References

Related entries

• containerd: Goroutine leak in the CRI stream server terminal-resize path exhausts host memoryCVE-2022-23471 · containerdMedium
• Argo Workflows (controller, daemon workflow SPDY client race): A data race in a global variable in the Kubernetes SPDYCVE-2024-47827 · Argo Workflows (controller, daemon workflow SPDY client race)Medium
• CRI-O: oversized /etc/passwd in a tenant image exhausts node memory when runAsUser is unknownCVE-2025-4437 · CRI-O (runAsUser resolution reads the container /etc/passwd into memory)Medium
• Docker Sandboxes: read-only host mounts stay writable at their virtio-fs shared-export pathCVE-2026-18171 · Docker Sandboxes (virtio-fs host-edge grant for read-only mounts)Medium
• BuildKit: NTFS junctions inside the cache root escape the cache mount on Windows container workersCVE-2026-15788 · BuildKitMedium
• containerd: CRI checkpoint import does not validate image references in checkpoint metadataCVE-2026-50195 · containerdMedium