CVE-2026-105942: CWE-863 Incorrect Authorization in Apache Software Foundation Apache Pulsar

This vulnerability in Apache Pulsar arises from two flaws in the authorization of proxied requests. First, the original principal was authorized using the proxy's authentication data rather than its own, affecting the admin REST API, functions worker, and the Pulsar binary protocol when the proxy does not forward client credentials. This flaw impacts deployments using the multi-role token authorization provider or custom providers that rely on authentication data, potentially allowing users to gain permissions from the proxy's token roles, including superuser or tenant admin roles. Second, the tenant admin check for proxied admin REST API requests succeeded if the proxy role was a tenant admin, without verifying the original principal's permissions, enabling any user forwarded by such a proxy to perform tenant administration. These issues affect Apache Pulsar versions >=2.8.1 <4.0.14 and >=4.1.0 <4.2.5. Fixed versions require both proxy role and original principal to be authorized independently with correct credentials, and tenant admin checks require both roles to be superusers or tenant admins. Users should upgrade to at least 4.0.14 for 4.0.x versions and 4.2.5 for 4.1.x and 4.2.x versions.

The vulnerability allows unauthorized users to perform operations requiring elevated permissions if their requests are proxied by a role with superuser or tenant admin privileges. Specifically, users can inherit permissions from the proxy's token roles or bypass tenant admin checks, potentially leading to unauthorized tenant administration and other privileged actions. This undermines the intended authorization model and can compromise the security of the Pulsar deployment.

A fix is available. Users should upgrade affected Apache Pulsar versions to at least 4.0.14 for the 4.0.x line and 4.2.5 for the 4.1.x and 4.2.x lines. The fixed versions ensure that both the proxy role and the original principal are authorized separately using their own authentication data, and tenant admin checks require both roles to have appropriate permissions. Deployments not using the multi-role token authorization provider or where no proxy role is a tenant admin are not affected by the respective flaws. No additional mitigation is required beyond applying the official fixes.