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/.
Published: 2026-10-21
Score: 7.7 High
EPSS: n/a
KEV: No
Impact: Privilege escalation via proxy misauthorization
Action: Immediate Patch
AI Analysis

Impact

A misconfiguration in the proxy authorization flow causes the broker to authorize the original principal with the proxy's authentication data rather than the original principal's own credentials. When a proxy authenticates using a token that includes privileged roles, the broker incorrectly grants those roles to the proxied user, allowing the user to perform actions reserved for superusers or tenant administrators. Additionally, the tenant admin check for proxied admin REST API requests overlooks the original principal when the proxy role itself is an admin of the tenant, enabling any forwarded user to execute tenant administration commands. This flaw is based on CWE‑863 and results in unauthorized privilege escalation without requiring the victim to possess those privileges themselves.

Affected Systems

The vulnerability applies to Apache Pulsar community releases from 2.8.1 up to 4.0.13, from 4.1.0 up to 4.2.4, and all earlier versions before 4.0.14 and 4.2.5. It requires the use of the MultiRolesTokenAuthorizationProvider or a custom provider that relies on authentication data, and it is triggered when a proxy role is granted tenant admin or superuser rights. Deployments that do not use the multi‑role token provider or that configure proxies without an admin token are not affected. The issue is present in versions 2.8.4 and later within the 2.8.x line, 2.9.3 and later within the 2.9.x, and 2.10.1 and later across subsequent releases.

Risk and Exploitability

The CVSS score of 7.7 indicates a high severity. EPSS is not available, so the current public exploitation likelihood is unknown, and the vulnerability is not listed in the CISA KEV catalog. The most probable attack vector involves an attacker controlling or compromising a proxy server that provides the broker with a token containing privileged roles, or taking advantage of a configuration where the proxy role is listed as a tenant admin. From that position, the attacker can issue proxied requests that are granted elevated permissions, leading to unrestricted access to data and administrative capabilities across the Pulsar tenant.

Generated by OpenCVE AI on October 22, 2026 at 01:51 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade Apache Pulsar to a patched release: at least 4.0.14 for the 4.0.x line or 4.2.5 for the 4.1.x and 4.2.x lines, or any newer release.
  • Reconfigure the proxy so that it does not authenticate to the broker with a token that contains superuser or tenant admin roles; if using the multi‑role token provider, ensure the token used by proxy only contains roles appropriate to its own identity.
  • Remove tenant admin or superuser privileges from the proxy role or create separate roles for proxy usage, so that proxied requests cannot inherit those privileged permissions.

Generated by OpenCVE AI on October 22, 2026 at 01:51 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 21 Oct 2026 18:30:00 +0000

Type Values Removed Values Added
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/.
Title Apache Pulsar: Original principal of proxied requests authorized with the proxy's authentication data, allowing privilege escalation
Weaknesses CWE-863
References
Metrics cvssV4_0

{'score': 7.7, 'vector': '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'}

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-10-21T18:14:35.996Z

Reserved: 2026-10-06T07:05:02.164Z

Link: CVE-2026-105942

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-21T19:16:57.203

Modified: 2026-10-21T19:16:57.203

Link: CVE-2026-105942

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-10-22T02:00:10Z

Weaknesses