CVE-2026-65956 in KubePi
Summary
by MITRE • 08/27/2026
KubePi is a Kubernetes multi-cluster management panel. In versions up to and including 1.6.15, the SSO configuration API endpoints are exposed on the same public routing boundary as the SSO login and callback endpoints, so SSO, OIDC, and SAML management operations can be reached without administrator authorization. Because reading, creating, and updating the global SSO configuration is not restricted to administrators, an unauthorized or low-privileged user can inspect or alter the authentication configuration, which under certain conditions can lead to account takeover or privilege escalation. The SSO connectivity-test function can additionally be abused as a server-side request forgery primitive, and the user list API returns user objects without consistently clearing authentication-related fields. This issue is fixed in version 2.0.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
KubePi serves as a multi-cluster management interface for Kubernetes environments, providing administrators with tools to oversee complex container orchestration infrastructures. In versions up to and including 1.6.15, the application exhibits significant architectural flaws regarding its Single Sign-On configuration endpoints. These API endpoints are exposed on the same public routing boundary as the SSO login and callback mechanisms, creating a critical misconfiguration where sensitive administrative functions become accessible without proper authorization controls. This design oversight allows any authenticated user, regardless of their privilege level, to interact with global authentication settings that should be strictly reserved for system administrators.
The core technical flaw lies in the absence of role-based access control on specific SSO management operations. An unauthorized or low-privileged user can inspect, create, and update the global Single Sign-On configuration parameters. This lack of restriction enables an attacker to modify how users authenticate into the KubePi platform. By altering these settings, a malicious actor can potentially redirect authentication flows, manipulate identity provider configurations, or disable security checks entirely. Such manipulation under certain conditions facilitates account takeover scenarios where attackers can impersonate legitimate administrators or escalate their privileges within the Kubernetes cluster by controlling the authentication layer itself.
Beyond direct configuration tampering, the vulnerability extends to data leakage and server-side request forgery risks. The user list API endpoint returns detailed user objects but fails to consistently clear sensitive authentication-related fields from its responses. This information disclosure provides attackers with valuable intelligence regarding internal users, their associated identities, and potentially cached tokens or session identifiers that could be exploited in further attacks. Additionally, the SSO connectivity-test function is implemented in a manner that allows it to be abused as a server-side request forgery primitive. Attackers can leverage this functionality to make arbitrary requests from the KubePi server to internal network resources, bypassing local firewalls and accessing services that are not directly exposed to the public internet.
The operational impact of these vulnerabilities is severe for organizations relying on KubePi for cluster management. The ability to alter SSO configurations undermines the integrity of the entire authentication infrastructure, potentially leading to widespread unauthorized access across multiple Kubernetes clusters managed by the platform. Combined with information disclosure and SSRF capabilities, an attacker can achieve persistent administrative control over critical containerized workloads, exfiltrate sensitive data, or pivot into internal network segments. These issues represent a fundamental failure in securing management interfaces against lower-privileged users, violating basic principles of least privilege and secure API design.
To mitigate these risks, organizations must immediately upgrade to version 2.0.0 or later, where the routing boundaries are properly segregated and access controls for SSO configuration endpoints have been enforced. Until an upgrade is feasible, administrators should implement network-level restrictions such as firewall rules or reverse proxy configurations to limit access to KubePi management interfaces exclusively from trusted administrative IP addresses. It is also critical to audit existing user permissions within older versions to ensure that no low-privileged accounts retain unnecessary privileges over authentication settings. Regular security assessments and penetration testing of the management plane are recommended to identify similar architectural flaws in other components of the Kubernetes ecosystem.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Escalation due to the ability of lower-privileged users to perform administrative actions. The information disclosure aspect corresponds to CWE-200 Exposure of Sensitive Information to an Unauthorized Actor, while the SSRF capability maps to CWE-918 Server-Side Request Forgery. In terms of attack tactics, these flaws facilitate initial access and privilege escalation techniques documented in the MITRE ATT&CK framework, specifically relating to credential manipulation and internal network discovery through server-side requests. Addressing these issues requires a holistic approach that combines software updates with strict identity and access management policies for all Kubernetes management tools.