CVE-2026-69129
MediumCVSS 5.8Exploitation Probability (EPSS)
Low risk15th percentile - higher than 15% of all known CVEs
Summary
KubePi up to version 2.0.0 does not consistently validate per-cluster access in cluster-scoped APIs, allowing an authenticated user with cluster management permissions to operate on clusters outside their granted scope. This issue is fixed in version 2.0.1.
Risk Assessment
Risk of unauthorized access to and modification of Kubernetes clusters that the user should not manage, potentially leading to confidentiality and integrity breaches.
Recommendation
Immediately upgrade KubePi to version 2.0.1 or later and review role and cluster configurations for excessive permissions.
Other vulnerabilities in KubePi
See all- CVE-2026-65956Critical
KubePi versions up to and including 1.6.15 expose SSO configuration API endpoints on the same public routing boundary as SSO login and callback endpoints, allowing SSO, OIDC, and SAML management without administrator authorization. Unauthorized users can inspect or alter authentication configuration, potentially leading to account takeover or privilege escalation. The SSO connectivity-test function can be abused as SSRF, and the user list API returns user objects without clearing authentication-related fields. Fixed in version 2.0.0.
- CVE-2023-37917Critical
KubePi is an opensource kubernetes management panel. A normal user has permission to create/update users, allowing them to gain admin rights by editing the `isadmin` value in the request.
- CVE-2023-37916Medium
KubePi is an opensource kubernetes management panel. The endpoint /kubepi/api/v1/users/search?pageNum=1&&pageSize=10 leaks password hashes of users, including admins, which may allow an attacker to crack them.
Original NVD description (English source)
KubePi is a Kubernetes multi-cluster management panel. In versions up to and including 2.0.0, cluster-scoped APIs do not consistently validate per-cluster access, allowing an authenticated user with cluster management permissions to operate on clusters outside the scope they were granted. Because the affected endpoints act on cluster-specific data without confirming that the requesting user is authorized for that particular cluster, a user assigned management rights over one cluster can, under certain role and cluster configurations, read or modify data in clusters they should not manage. This issue is fixed in version 2.0.1.