CVE-2026-105942
HighCVSS 7.7Exploitation Probability (EPSS)
Low risk32th percentile - higher than 32% of all known CVEs
Summary
Apache Pulsar contains two flaws in the authorization of requests forwarded by a proxy on behalf of another user. The first authorizes the original principal using the proxy's authentication data (affecting e.g. MultiRolesTokenAuthorizationProvider), and the second skips the original principal check for tenant admin operations when the proxy role is a tenant admin. This may allow users to perform operations beyond their own permissions.
Risk Assessment
Users whose requests are forwarded by an affected proxy may gain superuser or tenant admin capabilities and perform administrative operations without holding those permissions. This applies in particular to deployments using MultiRolesTokenAuthorizationProvider or custom providers that use authentication data, and to deployments where a proxy role is a tenant admin.
Recommendation
Upgrade Apache Pulsar to 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). If upgrading is not possible, review proxy configuration and tenant admin roles, and limit the use of MultiRolesTokenAuthorizationProvider and proxy tokens.
Other vulnerabilities in Apache Pulsar
See all- CVE-2026-105869Critical
A vulnerability in Apache Pulsar's MultiRolesTokenAuthorizationProvider allows a client to be authorized with all roles listed in an unverified JWT claim. When anonymousUserRole is set and authentication fails but falls back to anonymous, an unauthenticated client can send a forged or unsigned token with arbitrary roles and be authorized, potentially gaining super-user access.
- CVE-2026-105945High
The Apache Pulsar Packages Management Service with the FileSystemPackagesStorageProvider did not validate the version component of a package name, which could contain URL-encoded path separators and parent directory references. This allowed the filesystem storage provider to resolve the version to a location belonging to a package in a different tenant or namespace, and the containment check inside the storage directory did not prevent the access. An authenticated user with the packages permission on any namespace could download, overwrite or delete packages in other tenants or namespaces.
- CVE-2026-105938Low
Apache Pulsar did not apply subscription policies (Prefix subscription authentication mode or subscription permissions) in several admin REST API operations acting on subscriptions: clearing the backlog (for a named subscription and for all subscriptions), unsubscribe, and expiring messages for all subscriptions of a topic. An authenticated user with consume permission on the namespace or topic could bypass these policies and clear the backlog, expire messages, or delete a subscription that the policies would deny to that user.
- CVE-2026-105937High
A vulnerability in Apache Pulsar affects the shadow topics mechanism (PIP-180). The broker authorizes the caller only against the topic being created or updated, not against the source topic named in the PULSAR.SHADOW_SOURCE property. This allows an authenticated user with permission to create topics or update topic properties in one tenant to bind a topic to a source topic in another tenant and read its retained messages.
- CVE-2026-105936Medium
In Apache Pulsar, the functions connectors endpoint (/admin/v2/functions/connectors and /admin/v3/functions/connectors) returns the IO connector catalog without requiring super-user access, whereas the worker connectors endpoint enforces this check. As a result, any authenticated client can read the connector catalog metadata regardless of its role permissions. The issue affects versions from 2.4.1 before 4.0.14 and from 4.1.0 before 4.2.5.
- CVE-2026-105935Medium
The vulnerability affects the Apache Pulsar Functions Worker REST API trigger endpoint. The Worker publishes a message to the function's input topic using its own broker-client credentials rather than the caller's credentials, and does not verify that the caller is authorized to produce to that topic. Versions before 2.4.0 perform no caller authorization check for this endpoint at all.
- CVE-2026-105934High
Apache Pulsar broker versions 2.8.0 through 4.0.13 and 4.1.0 through 4.2.4 do not apply the tenant admin check to the caller for the truncate operation on a partitioned topic. Instead, the broker truncates each partition using its own internal admin client, so an authenticated user without tenant admin rights but with lookup permission can truncate any partitioned topic. This skips unacknowledged subscription backlog and permanently deletes older ledgers regardless of the namespace retention policy.
- CVE-2026-105933Low
Apache Pulsar allows administrators to enforce end-to-end message encryption for all topics in a namespace via the encryption_required namespace policy. If loading a persistent topic fails during initialization (e.g., metadata store read error or topic-level policy load failure), the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as successful. As a result, an authenticated client with produce permissions can publish unencrypted messages that the broker accepts and stores, even though the namespace policy requires encryption.
- CVE-2026-105932Low
The Apache Pulsar broker admin REST API endpoints for non-persistent topics (/admin/v2/non-persistent/.../entryFilters) do not perform the entry filters topic policy authorization check, unlike persistent topic endpoints. An authenticated user with produce or consume permission on a non-persistent topic can read, replace, or remove that topic's entry filter policy. This affects versions from 3.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.
- CVE-2026-105931Low
The Apache Pulsar broker exposes a transaction administration REST API under /admin/v3/transactions. When authentication and authorization are enabled, most read endpoints of this API verify only that the request is authenticated and that the broker serves the requested topic or transaction coordinator, without checking whether the caller is permitted to access the tenant, namespace or topic whose data is returned. As a result, any authenticated user, including one with no permissions, can read transaction coordinator and transaction information belonging to other tenants.
Original NVD description (English source)
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/.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS