Severity:
CVSS 4.0: 7.7 (high)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Affected versions:
- Apache Pulsar 2.8.1 before 4.0.14
- Apache Pulsar 4.1.0 before 4.2.5
Description:
When a configured proxy role sends a request to the broker on behalf of another
user (the original principal), the broker is designed to authorize both the
proxy role and the original principal and to allow the request only if both are
authorized, so that the original principal cannot exceed its own permissions.
Two flaws weakened this check.
First, the original principal was authorized with the proxy's authentication
data instead of its own. On the admin REST API of the broker and the functions
worker, this applied to every proxied request. On the Pulsar binary protocol,
it applied when the proxy did not forward the client's credentials to the
broker, which was the default of the Pulsar proxy in the affected versions.
Authorization providers that resolve permissions from the role name only, such
as the default authorization provider, are not affected by this flaw. The
multi-role token authorization provider (MultiRolesTokenAuthorizationProvider),
added in Apache Pulsar 2.8.1, resolves roles from the role claim of the token
in the authentication data it is given. When a proxy authenticates to the
broker with its own token, the original principal was therefore authorized with
all roles in the proxy's token. If any of those roles is a superuser or tenant
admin role, any user whose requests are forwarded by that proxy can perform
operations that need those permissions without holding them. Custom
authorization providers that use the authentication data could be affected in a
similar way.
Second, independently of the authorization provider, the tenant admin check of
a proxied admin REST API request succeeded without checking the original
principal when the proxy role was itself an admin role of the tenant. In
deployments where a proxy role is a tenant admin, including with the default
authorization provider, any user whose requests are forwarded by that proxy
could perform tenant administration operations on that tenant. This behavior is
present from 2.8.4 in the 2.8.x releases, from 2.9.3 in the 2.9.x releases, and
from 2.10.1 onwards.
Deployments that use neither the multi-role token authorization provider nor a
custom provider that uses the authentication data are not affected by the first
flaw, and with the multi-role token authorization provider, neither are
deployments whose proxies do not authenticate to the broker with a token.
Deployments in which no proxy role is listed as an admin role of a tenant are
not affected by the second flaw. A proxy role that is a superuser but is not
listed as a tenant admin does not trigger it, because the tenant admin check of
the built-in authorization providers only considers the tenant's admin roles;
this can differ for custom authorization providers that treat superusers as
tenant admins.
In fixed versions, both the proxy role and the original principal are
authorized for each proxied request, and the original principal is authorized
only with its own authentication data. With the multi-role token authorization
provider, the roles of a forwarded token are used for the original principal
only when that token authenticates as the original principal; otherwise only
the original principal's role name is used. For tenant admin checks, the proxy
role and the original principal must each be a superuser or a tenant admin of
the tenant.
This issue affects Apache Pulsar versions from 2.8.1 before 4.0.14 and from
4.1.0 before 4.2.5.
- 4.0.x version users should upgrade to at least 4.0.14.
- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
Users operating versions prior to those listed above should upgrade to the
aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The
supported versions schedule is available at
https://pulsar.apache.org/contribute/release-policy/.
References:
https://pulsar.apache.org/security/CVE-2026-105942/
https://pulsar.apache.org/
https://www.cve.org/CVERecord?id=CVE-2026-105942
