CVE-2026-69129: broken cluster-scope check exposes

CISO Take

KubePi, a Kubernetes multi-cluster management panel, fails to consistently verify that an authenticated user's cluster management permissions actually apply to the specific cluster targeted by a given API call, so a user with management rights on one cluster can read or modify resources in other clusters they were never granted access to. There is no CVSS score, EPSS data, public exploit, or Nuclei template for this issue, and it is not in CISA KEV, so there is no evidence of active exploitation — but the underlying bug class (CWE-639, authorization bypass through a user-controlled key) is a classic IDOR that requires only a valid low-privilege account and knowledge of a target cluster identifier, making it low-effort to exploit once discovered. For organizations using KubePi to operate multi-tenant Kubernetes environments that host AI/ML training or inference workloads, this breaks the tenant isolation that compliance and blast-radius assumptions depend on, letting one team's staging-cluster user reach a production model-serving cluster, its secrets, and its pipeline configuration. Patch to KubePi 2.0.1 immediately, and in the interim audit which accounts hold cluster-management roles and review logs for cross-cluster API calls referencing clusters outside a user's assigned scope.

Sources:NVDGitHub Advisory

What is the risk?

Unrated in CVSS/EPSS and absent from CISA KEV, with no public exploit or scanner template, so near-term mass exploitation is unlikely. However, the vulnerability class is a straightforward broken-object-level-authorization (IDOR) bug requiring only an existing authenticated account with cluster-management rights on any single cluster — no external network exposure or advanced tooling needed. The real risk driver is exposure, not sophistication: organizations running multi-tenant KubePi deployments where different teams (dev/staging vs. production, or different business units) are meant to be isolated per cluster face a meaningful cross-tenant confidentiality and integrity risk until patched.

How does the attack unfold?

Initial Access

Attacker obtains or already holds a valid KubePi account with cluster management permissions scoped to at least one lower-trust cluster.

AML.T0012

Exploitation

Attacker issues cluster-scoped API calls referencing the identifier of a different, unauthorized cluster; the missing per-cluster authorization check accepts the request.

Unauthorized Access

Attacker enumerates and reads or modifies resources in the unauthorized cluster, including secrets, deployments, and configuration tied to AI/ML workloads.

AML.T0007

Impact

Sensitive data (credentials, model artifacts) is exposed or production AI/ML services outside the attacker's granted scope are tampered with.

Initial Access

Attacker obtains or already holds a valid KubePi account with cluster management permissions scoped to at least one lower-trust cluster.

AML.T0012

Exploitation

Attacker issues cluster-scoped API calls referencing the identifier of a different, unauthorized cluster; the missing per-cluster authorization check accepts the request.

Unauthorized Access

Attacker enumerates and reads or modifies resources in the unauthorized cluster, including secrets, deployments, and configuration tied to AI/ML workloads.

AML.T0007

Impact

Sensitive data (credentials, model artifacts) is exposed or production AI/ML services outside the attacker's granted scope are tampered with.

How severe is it?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% 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.1 or later immediately — the fix is already released and referenced in the GitHub Advisory (GHSA-cwg7-34p9-9hxh) and the linked patch commit. Until upgraded, apply compensating controls: minimize the number of accounts holding cluster-management permissions on more than one cluster, avoid mixing trust levels (e.g., don't let staging-cluster admins also hold any role touching production clusters), and enforce Kubernetes-native RBAC and network segmentation as defense-in-depth so KubePi's own authorization layer is not the sole control. For detection, review KubePi and Kubernetes API server audit logs for requests where the cluster ID in the request path does not match a user's originally assigned cluster(s), and flag any cross-cluster read/write activity from non-admin accounts for investigation.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

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

How is it classified?

Auth BypassData LeakageInferenceTraining DataAML.T0007- Discover AI Artifacts

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

Annex A.7-Resources for AI systems

Frequently Asked Questions

What is CVE-2026-69129?

KubePi, a Kubernetes multi-cluster management panel, fails to consistently verify that an authenticated user's cluster management permissions actually apply to the specific cluster targeted by a given API call, so a user with management rights on one cluster can read or modify resources in other clusters they were never granted access to. There is no CVSS score, EPSS data, public exploit, or Nuclei template for this issue, and it is not in CISA KEV, so there is no evidence of active exploitation — but the underlying bug class (CWE-639, authorization bypass through a user-controlled key) is a classic IDOR that requires only a valid low-privilege account and knowledge of a target cluster identifier, making it low-effort to exploit once discovered. For organizations using KubePi to operate multi-tenant Kubernetes environments that host AI/ML training or inference workloads, this breaks the tenant isolation that compliance and blast-radius assumptions depend on, letting one team's staging-cluster user reach a production model-serving cluster, its secrets, and its pipeline configuration. Patch to KubePi 2.0.1 immediately, and in the interim audit which accounts hold cluster-management roles and review logs for cross-cluster API calls referencing clusters outside a user's assigned scope.

Is CVE-2026-69129 actively exploited?

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

How to fix CVE-2026-69129?

Upgrade KubePi to version 2.0.1 or later immediately — the fix is already released and referenced in the GitHub Advisory (GHSA-cwg7-34p9-9hxh) and the linked patch commit. Until upgraded, apply compensating controls: minimize the number of accounts holding cluster-management permissions on more than one cluster, avoid mixing trust levels (e.g., don't let staging-cluster admins also hold any role touching production clusters), and enforce Kubernetes-native RBAC and network segmentation as defense-in-depth so KubePi's own authorization layer is not the sole control. For detection, review KubePi and Kubernetes API server audit logs for requests where the cluster ID in the request path does not match a user's originally assigned cluster(s), and flag any cross-cluster read/write activity from non-admin accounts for investigation.

What systems are affected by CVE-2026-69129?

This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, MLOps orchestration, multi-cluster Kubernetes deployments.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

model servingtraining pipelinesMLOps orchestrationmulti-cluster Kubernetes deployments

MITRE ATLAS Techniques

AML.T0007Discover AI Artifacts

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.7

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An MLOps engineer or external contractor is granted KubePi cluster-management rights limited to a 'staging' cluster used for model experimentation. Through the KubePi UI, shared documentation, or simple enumeration, they learn the internal cluster identifier of the organization's 'production' cluster that hosts live model-serving deployments. Because KubePi's cluster-scoped API endpoints act on the cluster ID supplied in the request without confirming the caller is authorized for that specific cluster, the engineer replays or crafts an API call substituting the production cluster ID. The request succeeds, letting them list secrets, inspect deployment manifests, or modify configuration for production inference workloads — extracting registry credentials or model artifacts, or tampering with a service they were never granted access to manage.

Weaknesses (CWE)

CWE-639Authorization Bypass Through User-Controlled KeyPrimary CWE-639Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.