KubePi CVE-2026-65956: public SSO APIs exposed the Kubernetes panel control plane
KubePi through 1.6.15 mixed public login routes with OIDC and SAML administration. Analysis of takeover, SSRF, version 2.0.0 and safe migration.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 27 August 2026
- READING TIME
- 17 min read
- TOPIC
- Identity and Access
CVE-2026-65956 affects KubePi, a multi-cluster Kubernetes management panel. In releases through 1.6.15, the public routing boundary required for SSO login also included administrative operations. Reading, creating and modifying SSO, OIDC or SAML configuration, along with connectivity testing, was not correctly restricted to administrators. Under certain configurations, this allowed an actor to influence the global login process, take over an account or escalate privileges, while the test function provided an SSRF primitive.
The CVE record was published at 22:40 UTC on 26 August, which is 27 August in Poland. It carries CVSS 4.0 10.0 (Critical), while the GHSA page still displays a Moderate label. This is a real discrepancy between the metric included in the CVE data and the advisory interface label. It should not be hidden or resolved by arbitrarily selecting the more convenient rating. Operationally, conditions and blast radius matter more: the panel can hold credentials and permissions for several clusters.
A routing architecture flaw, not an OIDC flaw
SSO requires several endpoints to be available before a session exists. A user needs to initiate login, return to an identity-provider callback, retrieve status or pass through a SAML ACS. Those routes are intentionally public. The problem begins when the same router or middleware also covers functions that change trust: issuer address, client ID, secrets, attribute mapping, SAML metadata or connectivity tests.
KubePi’s public boundary included too many operations. The advisory says an unauthorised or low-privileged user could inspect or change global configuration. This breaks the separation between the login data plane and identity control plane. The fact that both endpoint groups are called “SSO” does not justify a shared policy.
The 2.0.0 fix leaves only login, callback, status and required SAML flows public. Configuration read, creation, update and testing now sit behind administrator checks. A minimal public endpoint gives the login page only the required authentication type instead of returning a complete configuration object.
How configuration changes can become account takeover
OIDC or SAML configuration tells an application whom to trust and how to interpret an identity. If an attacker can point it at a controlled issuer, replace metadata, alter identifier mapping or change another trust parameter, the application may accept the attacker’s assertion as a privileged identity. The exact chain depends on the provider, signature validation, user mapping and role mapping.
The advisory deliberately says “under certain conditions”. Not every change immediately produces an administrator. SSO may be disabled, a deployment may require an existing user, or new identities may always map to a minimal role. Allowing an unauthorised actor to change a global trust anchor is nevertheless a critical control failure.
KubePi manages clusters and namespaces assigned to its users. Taking over a panel administrator does not automatically equal cluster-admin in every connected cluster, but it exposes exactly the kubeconfigs, service accounts and roles granted to the panel. Impact must therefore be assessed per cluster rather than ending at KubePi’s user database.
SSRF through connectivity testing
A connectivity test sends a request from the KubePi server to a configured SSO endpoint. When an unauthorised user controls the address, the server becomes an intermediary into its internal network. Depending on protocol, redirects and response handling, this can enable service discovery, access to administrative interfaces or contact with metadata endpoints.
The advisory calls this server-side request risk and does not document credential theft from a particular cloud service. Do not claim a confirmed metadata leak without evidence. The threat model should still recognise that the panel process has a network position unavailable to an anonymous external client.
Role checks should be supplemented by positive scheme and host validation, rejection of loopback, link-local and private ranges, validation after every redirect, and DNS handling resilient to rebinding. A safer connectivity test uses a dedicated egress proxy with an identity-provider allowlist and strict response limits.
Excess authentication fields in user responses
The advisory also covers a user-list API that did not consistently clear authentication-related fields. This does not mean a plaintext password was returned. Risk depends on the actual fields and whether an attacker can use them. The general problem is common: serialising a domain user object without an explicit response model exposes more than an administrative screen needs.
The fix clears authentication fields before returning the list. A stronger pattern builds the response from an allowlist: identifier, display name, status and required roles. A new database-model field should not automatically appear in an API. Contract tests can reject future JSON containing hashes, secrets, tokens, recovery codes or internal provider identifiers.
Affected versions and migration consequences
Releases through 1.6.15 are affected and the fixed line begins with 2.0.0. This is a major-version jump, so treat it as more than replacing one binary. The repository says KubePi 2.0.0 uses Go 1.26 and Kubernetes client-go 0.36, supports Kubernetes from 1.24, and recommends versions 1.34–1.36.
Before migration, inventory connected cluster versions, SSO methods, kubeconfigs, roles, namespaces and API integrations. Back up configuration and the database using the product’s documented procedure, then test callback URIs and SAML metadata in staging. Do not restore an old image over a migrated database without a schema-compatibility plan.
If immediate upgrade is impossible, remove the panel from the public internet, restrict it through a trusted administrative VPN or reverse proxy, and block SSO management endpoints. Hiding a frontend menu is not a security control. The ingress or WAF rule must cover every HTTP method, API version and encoded path variant.
Post-upgrade verification
Test anonymous, ordinary and administrator roles separately. An anonymous user should receive only the minimum information needed to select SSO and use login or callback routes. Configuration reads, creates, updates and tests must fail. An ordinary user must also be unable to perform management operations or view the full object.
After valid login, verify user, group and role mapping and effective access to each cluster. A negative test should use a correctly signed identity with no administrator mapping. For SAML, validate issuer, audience, recipient and time conditions; for OIDC, validate issuer, audience, nonce or state, signature algorithm and JWKS retrieval.
Monitor 401/403 outcomes, SSO configuration changes and KubePi outbound traffic. Alert on identity management outside a change window, a new issuer, a callback change, tests to private addresses and the first administrator login through a new provider.
Response when the panel was public
Preserve reverse-proxy, application, identity-provider and Kubernetes audit logs. Determine whether anyone read or modified configuration, ran connectivity tests or listed users. Compare current settings with approved IaC or a known-good backup, then inspect newly created administrator sessions.
If takeover cannot be excluded, rotate SSO client secrets, invalidate KubePi sessions and replace kubeconfigs or service-account tokens available to the panel. Review cluster actions including ClusterRoleBinding creation, secrets, privileged workloads, admission webhooks and image changes. Rotating only the panel can leave persistence inside Kubernetes.
Source facts and Breachroad conclusions
Affected versions, public SSO operations, takeover or escalation risk, SSRF, user-response fields and the fix come from KubePi’s advisory and CVE record. CVSS 10.0 comes from the CVE data, while Moderate is the GHSA page label; the discrepancy is preserved. The sources do not report active exploitation. Segmentation, detection, rotation and audit-log recommendations are Breachroad conclusions.
Cloud, Kubernetes and identity security training helps teams separate public login from an administrative control plane, while application and infrastructure security assessments can validate SSO endpoints, SSRF controls and the panel’s real blast radius.
