How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows JWT bearer tokens to be exposed through URL query parameters, which can be logged in reverse-proxy access logs, browser history, and HTTP Referer headers. Such exposure can lead to unauthorized access to user privileges until the token expires.

The leakage of authentication tokens could result in unauthorized access to sensitive data or systems, potentially violating data protection requirements under regulations like GDPR and HIPAA that mandate strict controls on access to personal and health information.

Therefore, this vulnerability may negatively impact compliance with standards that require secure handling of authentication credentials and protection of user data.

Useful 0 Not Useful 0

Can you explain this vulnerability to me?

This vulnerability affects Portainer Community Edition versions from 2.33.0 to before 2.33.8, 2.39.2, and 2.41.0. The issue is that Portainer's authentication middleware accepts JWT bearer tokens passed as a URL query parameter (?token=<JWT>) on any authenticated API endpoint, in addition to the standard Authorization: Bearer header.

Because URLs containing the token are recorded in reverse-proxy access logs, browser history, and HTTP Referer headers, the JWT tokens can be exposed to anyone with access to these logs or to external sites visited by the user afterward.

A leaked token grants the full privileges of the user it was issued to until the token expires (default 8 hours). The ?token= parameter was used by Portainer's browser-based container attach, exec, and pod shell features, exposing any user with exec or attach rights on a container, not just administrators.

This vulnerability has been fixed in versions 2.33.8, 2.39.2, and 2.41.0.

Useful 0 Not Useful 0

How can this vulnerability impact me? :

If exploited, this vulnerability can lead to unauthorized access to user accounts by leaking JWT tokens through logs, browser history, or HTTP Referer headers.

An attacker who obtains a leaked token can gain the full privileges of the user associated with that token until it expires, potentially allowing them to execute commands or attach to containers.

This means that users with exec or attach rights on containers, not just administrators, are at risk of having their sessions hijacked, which could lead to unauthorized actions within the containerized environment.

Useful 0 Not Useful 0

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves JWT bearer tokens being passed as a ?token=<JWT> URL query parameter on authenticated API endpoints, which can be logged in reverse-proxy access logs, browser history, and HTTP Referer headers.

To detect this vulnerability on your network or system, you can inspect your reverse-proxy access logs and web server logs for URLs containing the ?token= parameter.

• Use grep or similar tools to search logs for '?token=' strings, for example: grep '\?token=' /var/log/nginx/access.log
• Check browser history or HTTP Referer headers for URLs containing the ?token= parameter.

Additionally, review API endpoint usage to identify if any requests are passing JWT tokens via URL parameters instead of the Authorization header.

Useful 0 Not Useful 0

What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed in Portainer Community Edition versions 2.33.8, 2.39.2, and 2.41.0.

• Upgrade Portainer Community Edition to version 2.33.8 or later, or to 2.39.2 or 2.41.0 as applicable.
• Avoid passing JWT tokens via the ?token= URL query parameter; use the standard Authorization: Bearer header instead.
• Review and restrict user permissions to limit who can use exec or attach rights on containers, as these users are exposed.
• Clear or secure reverse-proxy access logs and browser histories that may contain leaked tokens.

Useful 0 Not Useful 0