The flaw lies within the kubeClientMiddleware of Portainer Community and Enterprise editions. When a token validation error occurs, the middleware emits a 403 response but fails to halt execution, allowing the request to reach the Kubernetes handler with a nil tokenData. Because the outer AuthenticatedAccess gate only verifies that the user has a valid Portainer session, an attacker who forces secondary token validation to fail—such as a user lacking permission for a particular Kubernetes endpoint—can still proxy that request to the cluster. The result is unauthorized access to Kubernetes resources, potentially allowing an attacker to read or modify data, expose secrets or deploy malicious workloads. This directly violates the principle of least privilege and introduces a serious privilege‑escalation vector.

Portainer users running the Community and Enterprise editions are affected. The vulnerability exists in all releases from version 2.33.0 up through 2.33.7 (and any patch series that includes these missing return statements). Both CE and EE codebases share the defect, so any deployment of Portainer older than 2.33.8 is vulnerable regardless of the edition.

The CVSS score of 8.1 classifies this flaw as high severity. Because the EPSS score is not available and the vulnerability is not yet listed in CISA's KEV catalog, the exploitation probability is uncertain, but the need for a valid Portainer session suggests a moderate attack complexity. The flaw allows bypassing Kubernetes access controls for users who normally cannot reach certain endpoints, which means an attacker can elevate privileges within the cluster and potentially gain full control over cluster resources. The attack vector is an authenticated session to Portainer, followed by a request to a Kubernetes endpoint that the user normally lacks permission to access.