Portainer’s authentication middleware allowed JWT bearer tokens to be supplied as a ?token=<JWT> URL query parameter on any authenticated API endpoint in addition to the standard Authorization header. The vulnerability caused the token to be logged in reverse‑proxy access logs, stored in browser history, and transmitted in HTTP Referer headers. A leaked token grants the full privileges of the account that issued it until expiry, which defaults to eight hours. This issue could thus enable unauthorized users to acquire administrative or container‑execution rights without compromising the underlying system credentials.

The vulnerability affects Portainer Community Edition versions 2.33.0 through 2.33.7, as well as any 2.39.x version prior to 2.39.2 and any 2.41.x version prior to 2.41.0. An attacker can exploit affected instances via any authenticated API endpoint that accepts the ?token= query parameter. Containers, pods, and services that a user can attach to or execute commands on are at risk because the query parameter is used by these features.

The CVSS score of 7.7 indicates a high severity vulnerability. EPSS data is not available, and the vulnerability is not listed in the CISA KEV catalog, so the probability of exploitation remains uncertain. Based on the description, it is inferred that an attacker must have access to reverse‑proxy access logs, browser history, or be able to observe outbound HTTP Referer headers to capture the leaked token. If such access is obtained, the attacker can reuse the token to impersonate the issuer until the token expires. The exploit path involves appending a ?token= query string with a valid bearer token to a request to an authenticated API endpoint; the resulting log entry or referer header can be harvested and replayed.