Portainer's Kubernetes middleware continues after token validation failure, bypassing endpoint authorization
Date: 2026-05
Affected: go/github.com/portainer/portainer
Attack vector: other
Category: vulnerability-disclosure
Severity: Critical
CVE: CVE-2026-44848
CVE-2026-44850
CVE-2026-44881
CVE-2026-44882
CWE: CWE-200
CWE-59
CWE-862
CWE-863
CVSS: 8.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)

## Summary Portainer proxies requests to Kubernetes clusters through a middleware layer (`kubeClientMiddleware`) that validates the requesting user's token before forwarding traffic to the cluster. When `security.RetrieveTokenData` returned an error, the middleware wrote an HTTP 403 response but was missing a `return` statement — execution continued into the handler with a nil `tokenData` value. The Kubernetes endpoints sit behind Portainer's outer `AuthenticatedAccess` bouncer, so an attacker requires a valid Portainer session. However, a user whose secondary token validation fails in `kubeClientMiddleware` — for example a user without permission to access a given Kubernetes endpoint — would have their request forwarded to the cluster anyway, bypassing the authorization check. The same defect was present in both the CE and EE codebases. ## Severity **High** **CWE-863** — Incorrect Authorization Privilege required is Low — any valid Portainer session is sufficient to reach the middleware. Once the authorization outcome is bypassed, the attacker can read and modify Kubernetes resources on the target endpoint that their role should not permit — confidentiality and integrity impact are both High. No availability impact is introduced directly. ## Affected Versions The missing `return` statement has been present since Kubernetes proxy support was introduced. | Branch | First vulnerable | Fixed in | |--------------|------------------|------------| | 2.33.x (LTS) | 2


Mitigations:

Architectural layers (MAESTRO):