CVE-2026-65956: exposed SSO config API enables

CISO Take

KubePi, a Kubernetes multi-cluster management panel, ships versions up to 1.6.15 with its SSO/OIDC/SAML configuration endpoints reachable on the same unauthenticated routing path as the login and callback endpoints, meaning an attacker with no credentials — or a low-privileged user — can read, create, or alter the identity provider settings that govern who gets admin access to the panel. Because there is no exploitation telemetry available (no EPSS score, not in CISA KEV, no public PoC or Nuclei template), this looks pre-weaponization, but the primitive is severe: an attacker who can point SSO configuration at an attacker-controlled IdP can mint themselves an authenticated session and escalate to full administrative control of every Kubernetes cluster KubePi manages. The bundled SSRF-capable connectivity-test function and a user-list API that leaks authentication-related fields compound the blast radius by giving an attacker both an internal network probe and credential material once inside. For any organization running AI/ML workloads (training jobs, model-serving pods, MLOps pipelines) on clusters administered through KubePi, this is a path from an internet-facing management panel straight to the infrastructure layer underneath the AI stack. Patch to KubePi 2.0.0 immediately, and until then restrict network access to the KubePi panel (VPN/allowlist), audit SSO configuration and user-list API access logs for unexpected reads/writes, and rotate any credentials exposed via the user-list endpoint.

Sources:NVDGitHub Advisory

What is the risk?

No CVSS score has been published, but the underlying flaw (CWE-306, missing authentication for a critical function) is structurally severe: it exposes the identity/authorization control plane itself, not a peripheral feature. Exploitability is low-effort — no exotic tooling is required, just direct HTTP requests to an exposed API path — but there is currently no evidence of active exploitation, no KEV listing, and no public exploit code or scanner template, so real-world exploitation likelihood is unconfirmed. The realistic worst case (SSO hijack → admin account takeover → full cluster control) pushes actual risk well above what an absent CVSS score suggests, especially for internet-facing deployments.

How does the attack unfold?

Initial Access

Attacker locates an internet-exposed KubePi panel and finds the SSO configuration API reachable on the same unauthenticated path as the public login/callback endpoints.

AML.T0049

Exploitation

Attacker reads or modifies the global SSO/OIDC/SAML configuration without administrator authorization, or abuses the connectivity-test function as an SSRF primitive.

AML.T0049

Privilege Escalation

By redirecting SSO to an attacker-controlled identity provider, the attacker completes login and is granted an authenticated, potentially admin-level KubePi session.

Impact

With administrative access to KubePi, the attacker gains control over managed Kubernetes clusters hosting AI/ML training, inference, or MLOps workloads, enabling data exfiltration or workload tampering.

Initial Access

Attacker locates an internet-exposed KubePi panel and finds the SSO configuration API reachable on the same unauthenticated path as the public login/callback endpoints.

AML.T0049

Exploitation

Attacker reads or modifies the global SSO/OIDC/SAML configuration without administrator authorization, or abuses the connectivity-test function as an SSRF primitive.

AML.T0049

Privilege Escalation

By redirecting SSO to an attacker-controlled identity provider, the attacker completes login and is granted an authenticated, potentially admin-level KubePi session.

Impact

With administrative access to KubePi, the attacker gains control over managed Kubernetes clusters hosting AI/ML training, inference, or MLOps workloads, enabling data exfiltration or workload tampering.

How severe is it?

CVSS 3.1

N/A

EPSS

0.6%

chance of exploitation in 30 days

Higher than 51% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade KubePi to version 2.0.0 or later, which fixes the routing/authorization boundary between SSO config and SSO login/callback endpoints. Until patched, place the KubePi panel behind a VPN or IP allowlist so SSO configuration and management endpoints are not internet-reachable, and disable or restrict the SSO connectivity-test feature where possible to eliminate the SSRF vector. Review SSO/OIDC/SAML configuration history and audit logs for unauthorized changes, and treat any anomalous IdP endpoint changes as a potential compromise indicator. Rotate credentials for any accounts whose data may have been exposed via the user-list API, and review outbound network logs from the KubePi host for signs of SSRF probing against internal services or cloud metadata endpoints (e.g., 169.254.169.254).

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassPrivacy ViolationInferenceAML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.2-Security controls for AI system infrastructure

NIST AI RMF

GOVERN 1.5-Ongoing monitoring and risk management of third-party/infrastructure components

Frequently Asked Questions

What is CVE-2026-65956?

KubePi, a Kubernetes multi-cluster management panel, ships versions up to 1.6.15 with its SSO/OIDC/SAML configuration endpoints reachable on the same unauthenticated routing path as the login and callback endpoints, meaning an attacker with no credentials — or a low-privileged user — can read, create, or alter the identity provider settings that govern who gets admin access to the panel. Because there is no exploitation telemetry available (no EPSS score, not in CISA KEV, no public PoC or Nuclei template), this looks pre-weaponization, but the primitive is severe: an attacker who can point SSO configuration at an attacker-controlled IdP can mint themselves an authenticated session and escalate to full administrative control of every Kubernetes cluster KubePi manages. The bundled SSRF-capable connectivity-test function and a user-list API that leaks authentication-related fields compound the blast radius by giving an attacker both an internal network probe and credential material once inside. For any organization running AI/ML workloads (training jobs, model-serving pods, MLOps pipelines) on clusters administered through KubePi, this is a path from an internet-facing management panel straight to the infrastructure layer underneath the AI stack. Patch to KubePi 2.0.0 immediately, and until then restrict network access to the KubePi panel (VPN/allowlist), audit SSO configuration and user-list API access logs for unexpected reads/writes, and rotate any credentials exposed via the user-list endpoint.

Is CVE-2026-65956 actively exploited?

No confirmed active exploitation of CVE-2026-65956 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-65956?

Upgrade KubePi to version 2.0.0 or later, which fixes the routing/authorization boundary between SSO config and SSO login/callback endpoints. Until patched, place the KubePi panel behind a VPN or IP allowlist so SSO configuration and management endpoints are not internet-reachable, and disable or restrict the SSO connectivity-test feature where possible to eliminate the SSRF vector. Review SSO/OIDC/SAML configuration history and audit logs for unauthorized changes, and treat any anomalous IdP endpoint changes as a potential compromise indicator. Rotate credentials for any accounts whose data may have been exposed via the user-list API, and review outbound network logs from the KubePi host for signs of SSRF probing against internal services or cloud metadata endpoints (e.g., 169.254.169.254).

What systems are affected by CVE-2026-65956?

This vulnerability affects the following AI/ML architecture patterns: MLOps infrastructure, model serving, training pipelines.

What is the CVSS score for CVE-2026-65956?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

MLOps infrastructuremodel servingtraining pipelines

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.6.2.2

NIST AI RMF: GOVERN 1.5

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker scans for internet-exposed KubePi instances and discovers that the SSO configuration API is reachable without authentication alongside the public login/callback routes. They query the SSO config endpoint to read the current OIDC/SAML setup, then submit a crafted update pointing the SSO identity provider to an attacker-controlled server. When the attacker completes the SSO login flow against their own fake IdP, KubePi trusts the assertion and grants them an authenticated (potentially admin-level) session. From there, they use their access to enumerate managed Kubernetes clusters, abuse the SSRF-capable connectivity-test function to probe internal cloud infrastructure, and pivot into clusters hosting AI/ML training or inference workloads to exfiltrate data or tamper with running jobs.

Weaknesses (CWE)

CWE-306Missing Authentication for Critical FunctionalityPrimary CWE-306Missing Authentication for Critical Functionality

CWE-306 — Missing Authentication for Critical Functionality: The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

[Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability. Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port. In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.