Listen to this Post
How the mentioned CVE works:
The vulnerability exists in Portainer’s kubeClientMiddleware, which proxies Kubernetes API requests.
When a user with a valid Portainer session accesses a Kubernetes endpoint, the middleware calls security.RetrieveTokenData(r) to validate the user’s token.
If this function returns an error (e.g., due to missing permissions for that specific endpoint), the middleware writes an HTTP 403 Forbidden response via httperror.WriteError.
However, the code lacks a return statement after writing the error.
Consequently, execution continues into the handler even though tokenData is nil.
The next line dereferences tokenData.ID, but because tokenData is nil, a panic would normally occur.
Nevertheless, the proxy logic that forwards the request to the Kubernetes cluster may still be invoked before the panic, depending on error handling paths.
In practice, the absence of a return allows the request to bypass the authorization check and reach the cluster.
An attacker only needs a low-privilege Portainer session (any authenticated user) and knowledge of a Kubernetes endpoint accessible by Portainer.
The outer AuthenticatedAccess bouncer ensures the user is logged in, but the secondary token validation in the middleware is where the bypass happens.
The defect is present in both Community Edition (CE) and Enterprise Edition (EE).
The vulnerability has existed since Kubernetes proxy support was introduced (first vulnerable version 2.33.0).
Fixed in 2.33.8 (LTS backport) and 2.39.0 (initial fix).
No configuration workaround fully prevents the bypass; only upgrading or restricting endpoint access reduces risk.
CWE-863 (Incorrect Authorization) applies.
Privilege required: Low.
Confidentiality and Integrity impact: High. Availability: None.
dailycve form:
Platform: Portainer CE/EE
Version: 2.33.0-2.33.7
Vulnerability: Authorization Bypass
Severity: High
date: 2026-05-07
Prediction: 2026-05-07
What Undercode Say:
Check Portainer version curl -k https://portainer:9443/api/status | jq '.version' Simulate bypass attempt (requires session cookie) curl -k -X GET \ -H "Authorization: Bearer <session_token>" \ "https://portainer:9443/api/endpoints/<endpoint_id>/kubernetes/api/v1/namespaces/default/secrets" Audit Portainer RBAC for least privilege kubectl get clusterrole portainer-proxy -o yaml kubectl describe serviceaccount portainer-sa -n portainer Monitor for nil tokenData panics in logs docker logs portainer | grep -i "panic|nil tokenData"
Exploit:
1. Obtain any valid Portainer session (low-privilege user).
- Identify a Kubernetes endpoint ID accessible via Portainer.
- Craft a request to that endpoint’s Kubernetes API (e.g., listing pods or secrets).
- Ensure the user lacks explicit permission for that endpoint, triggering RetrieveTokenData error.
- The middleware sends HTTP 403 but continues, forwarding request to cluster.
- Read or modify Kubernetes resources using Portainer’s service account permissions.
Protection from this CVE
- Upgrade to Portainer 2.33.8 or 2.39.0+ immediately.
- If unable to upgrade, remove Kubernetes endpoint access for all low-privilege users.
- Restrict Portainer’s Kubernetes service account to least-privilege RBAC (read-only where possible).
- Monitor audit logs for unexpected Kubernetes API calls from Portainer.
Impact
- Unauthorized read/write of Kubernetes secrets, configmaps, deployments, and pods.
- Lateral movement via stolen credentials from secrets.
- Full cluster compromise if Portainer service account has high privileges.
- No availability impact.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
