CVE-2026-69129: KubePi Privilege Escalation Vulnerability

CVE-2026-69129 Overview

CVE-2026-69129 is a broken access control vulnerability in KubePi, an open-source Kubernetes multi-cluster management panel maintained by 1Panel. In versions up to and including 2.0.0, cluster-scoped API endpoints fail to consistently validate per-cluster access. An authenticated user granted management permissions over one cluster can read or modify data belonging to clusters outside their assigned scope. The flaw is tracked under CWE-639: Authorization Bypass Through User-Controlled Key and is fixed in version 2.0.1.

Critical Impact
An authenticated cluster manager can pivot laterally across tenant boundaries, gaining unauthorized read or write access to Kubernetes clusters they were never authorized to administer.

Affected Products

KubePi versions up to and including 2.0.0
1Panel-dev/KubePi multi-cluster management panel
Fixed in KubePi 2.0.1

Discovery Timeline

2026-08-26 - CVE-2026-69129 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-69129

Vulnerability Analysis

KubePi exposes REST endpoints that operate on cluster-specific resources such as Helm charts, cluster access records, and cluster configuration. Prior to version 2.0.1, several of these handlers accepted a cluster identifier from the request but did not verify that the authenticated caller held an access binding for that specific cluster. The service layer trusted the session's global role rather than confirming per-cluster authorization.

Because KubePi is designed for multi-tenant, multi-cluster operations, this gap breaks the trust boundary between tenants. A user with legitimate management rights on cluster A can supply the identifier of cluster B and have the API execute the request against cluster B.

Root Cause

The root cause is missing authorization checks in cluster-scoped handlers under internal/api/v1/. Endpoints read the target cluster from path or query parameters but never cross-reference the caller's identity with the clusteraccess service before dispatching operations. The patch introduces a shared helper, userAccessFromContext, and a dedicated error ErrClusterAccessDenied to enforce the check uniformly.

Attack Vector

Exploitation requires an authenticated KubePi account that already holds management rights over at least one cluster. The attacker substitutes the cluster identifier in an affected API request with the identifier of a cluster they should not manage. The server processes the request without validating the caller's binding to that cluster.

// Patch excerpt: internal/api/v1/cluster/access.go
// Source: https://github.com/1Panel-dev/KubePi/commit/8e6ceefc68f374225aba2e6bc1905bb4210e6045
package cluster

import (
	"errors"

	"github.com/1Panel-dev/KubePi/internal/api/v1/session"
	"github.com/1Panel-dev/KubePi/internal/service/v1/clusteraccess"
	"github.com/1Panel-dev/KubePi/internal/service/v1/common"
	"github.com/asdine/storm/v3"
	"github.com/kataras/iris/v12"
	"github.com/kataras/iris/v12/context"
)

func userAccessFromContext(ctx *context.Context) (clusteraccess.User, bool) {
	profile, ok := ctx.Values().Get("profile").(session.UserProfile)
	if !ok || profile.Name == "" {
		ctx.StatusCode(iris.StatusUnauthorized)
		ctx.Values().Set("message", "please login")
		return clusteraccess.User{}, false
	}
	return clusteraccess.User{Name: profile.Name, IsAdministrator: profile.IsAdministrator}, true
}

func writeClusterAccessError(ctx *context.Context, err error) {
	if errors.Is(err, clusteraccess.ErrClusterAccessDenied) {
		ctx.StatusCode(iris.StatusForbidden)
		ctx.Values().Set("message", "user can not access cluster")
		return
	}
	ctx.StatusCode(iris.StatusInternalServerError)

The added helper resolves the caller from the session context, and writeClusterAccessError returns HTTP 403 when the user lacks access to the requested cluster. See the GitHub commit 8e6ceef for the full fix across chart.go and access.go.

Detection Methods for CVE-2026-69129

Indicators of Compromise

KubePi audit or access logs showing a single user account issuing API requests referencing cluster identifiers that are not present in their assigned cluster-access bindings.
Kubernetes control plane audit events initiated through KubePi service accounts against clusters the requesting KubePi user should not manage.
Unexpected modifications to Helm charts, workloads, or cluster access records performed by non-administrator KubePi users across multiple clusters in a short interval.

Detection Strategies

Correlate KubePi HTTP request logs with the clusteraccess bindings table to identify requests where the caller has no binding for the target cluster.
Baseline each KubePi user's normal set of managed clusters and alert on first-time access to a new cluster identifier by that user.
Inspect Kubernetes API server audit logs for lateral activity originating from KubePi kubeconfig credentials outside their expected tenant scope.

Monitoring Recommendations

Forward KubePi application logs and Kubernetes audit logs to a central analytics platform for cross-cluster correlation.
Monitor the running KubePi container image tag and alert when it reports a version at or below 2.0.0.
Track HTTP 403 rates on cluster-scoped endpoints after upgrade; a sudden spike may indicate previously abusive access patterns now being blocked by the fix.

How to Mitigate CVE-2026-69129

Immediate Actions Required

Upgrade all KubePi deployments to version 2.0.1 or later, available at the KubePi Release v2.0.1 page.
Review the current KubePi user list and revoke cluster management rights that are no longer required, applying least privilege.
Rotate kubeconfig credentials and service account tokens used by KubePi to reach managed clusters, in case they were exposed through cross-cluster abuse.

Patch Information

The fix is delivered in KubePi 2.0.1 through commit 8e6ceef, which enforces cluster access checks in internal/api/v1/chart/chart.go and adds shared authorization helpers in internal/api/v1/cluster/access.go. Full details are published in GitHub Security Advisory GHSA-cwg7-34p9-9hxh.

Workarounds

Restrict network access to the KubePi web interface so only trusted operators can authenticate while the upgrade is scheduled.
Temporarily reduce accounts with cluster management roles to a minimal set of trusted administrators until the patched version is deployed.
Place KubePi behind an authenticating reverse proxy that enforces additional per-cluster authorization at the URL path level.

bash

# Configuration example: verify installed KubePi version and upgrade
docker inspect --format '{{.Config.Image}}' kubepi

# Pull and redeploy the patched release
docker pull 1panel/kubepi:v2.0.1
docker stop kubepi && docker rm kubepi
docker run -d --name kubepi \
  -p 80:80 \
  -v /opt/kubepi:/var/lib/kubepi \
  1panel/kubepi:v2.0.1