EUVD-2026-107477
GHSA-6p73-4278-xh8r
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privileged user
-
DeliverySend request via Pulsar proxy to broker
-
ExploitBroker authorizes principal with proxy's token/role
-
ExecutionInherit superuser or tenant-admin roles
-
ImpactPerform unauthorized admin operations
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an authenticated low-privileged principal whose requests are forwarded through a configured Pulsar proxy, PLUS one of two concrete configurations. Flaw 1: the broker uses MultiRolesTokenAuthorizationProvider (added in 2.8.1) or a custom authorization provider that resolves permissions from the authentication data, AND the proxy authenticates to the broker with its own token - for the binary protocol this triggers only when the proxy does not forward client credentials (the default behavior of the affected Pulsar proxy versions), while on the admin REST API and functions worker it applies to every proxied request. Flaw 2: a proxy role is explicitly listed as a tenant admin of a tenant (present from 2.8.4/2.9.3/2.10.1), which bypasses the tenant-admin check even with the default authorization provider. LIMITING FACTORS: deployments using only the default role-name-based authorization provider are not affected by Flaw 1; a proxy that is a superuser but not a listed tenant admin does NOT trigger Flaw 2 under built-in providers; and deployments where proxies do not authenticate with a token are unaffected by the MultiRolesTokenAuthorizationProvider variant. Valid authentication (PR:L) is required throughout. |
| Impact | This is a CWE-863 authorization bypass in Apache Pulsar's proxy-to-broker principal check, scored 7.7 (High) under CVSS 4.0 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H). The signals are internally consistent and point to a real but conditional priority rather than a blanket emergency. AT:P (attack requirements present) and PR:L correctly capture that this is NOT a default-everywhere remote-unauth flaw: exploitation requires an existing low-privileged authenticated user AND one of two specific deployment conditions - either the MultiRolesTokenAuthorizationProvider (or a custom provider that consumes authentication data) combined with a proxy that authenticates to the broker using its own token, or a proxy role that is itself listed as a tenant admin. No EPSS score was provided and the CVE is not on CISA KEV; no public exploit is referenced. There is therefore no evidence of active exploitation or automatable mass exploitation. The high VC/VI/VA impact is justified because a successful bypass yields superuser or tenant-admin capabilities, but the gating conditions mean many deployments (notably those using only the default role-name-based authorization provider with no proxy acting as tenant admin) are not affected at all. Treat as a prioritized patch for Pulsar operators who run a proxy with token auth and MultiRolesTokenAuthorizationProvider, or whose proxy role is a tenant admin; lower urgency for default-provider deployments with no admin proxy role. |
| Exploit ScenarioDerived | In a Pulsar deployment using MultiRolesTokenAuthorizationProvider, a low-privileged tenant user sends admin REST API or binary-protocol requests through the proxy; because the broker authorizes the original principal using the proxy's own token (which carries superuser or tenant-admin roles), the user's request is granted those elevated roles and they perform administrative operations they do not hold. Alternatively, where the proxy role is listed as a tenant admin, the broker's tenant-admin check passes without validating the forwarded principal, letting any forwarded user perform tenant administration. No public exploit code is referenced, and exploitation requires valid low-level credentials plus the specific proxy/provider configuration. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Apache Pulsar 2.8.1 through 4.0.13 and 4.1.0 through 4.2.4 can grant an authenticated low-privileged user the proxy's full privilege set - including superuser and tenant-admin rights - on the broker admin REST API, the functions worker, and the binary protocol when their requests are relayed by a Pulsar proxy. Two distinct weaknesses in the proxy-to-broker principal check (CWE-863) are involved: the original principal is authorized with the proxy's authentication data, letting MultiRolesTokenAuthorizationProvider or a custom data-driven provider expand the caller's roles to every role in the proxy's token, and a separate tenant-admin check succeeds whenever the proxy role itself is an admin of the tenant, even under the default provider. No public exploit code has been identified at time of analysis; exposure is limited to deployments that use the multi-role token provider or a data-driven custom provider, or that list a proxy role as a tenant admin.
RemediationAI
Vendor-released patch: upgrade 4.0.x deployments to Apache Pulsar 4.0.14 or later and 4.1.x/4.2.x deployments to 4.2.5 or later (5.0.x is already fixed); per the release policy at https://pulsar.apache.org/contribute/release-policy/ only 4.0.x and 5.0.x remain supported, so migrating to a supported line is advisable. Where immediate upgrading is not possible, close the two paths the advisory describes. For the first flaw, configure the Pulsar proxy to forward client credentials to the broker instead of authenticating with its own token - this removes the binary-protocol variant at the cost of requiring end clients to present credentials the broker can validate - and stop using MultiRolesTokenAuthorizationProvider or any custom provider that derives permissions from authentication data, in favor of a role-name-only provider such as the built-in default; alternatively, ensure the proxy's own token carries no superuser or tenant-admin roles, which limits what the misapplied authentication data can grant. For the second flaw, remove the proxy role from every tenant's admin role list so the tenant-admin short-circuit no longer applies, accepting that the proxy then cannot perform tenant administration on behalf of legitimate tenant admins. Note that granting the proxy superuser status without listing it as a tenant admin does not trigger the second flaw under built-in providers, but superuser roles in the proxy token still aggravate the first flaw. Advisory: https://pulsar.apache.org/security/CVE-2026-105942/.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Apache Pulsar is a distributed publish-subscribe messaging and streaming platform whose proxy component forwards client traffic to brokers; for proxied requests the broker is designed to authorize both the proxy role and the original principal using the principal's own credentials, so that a proxy can never be used to exceed the caller's own permissions. CVE-2026-105942, classified as CWE-863 (Incorrect Authorization), breaks that invariant in two ways. First, the original principal is evaluated against the authentication data supplied by the proxy rather than its own - on the admin REST API and functions worker for every proxied request, and on the binary protocol whenever the proxy does not forward client credentials to the broker (the default behavior in the affected versions); this matters because MultiRolesTokenAuthorizationProvider, added in Pulsar 2.8.1, derives a set of roles from the role claim of whatever token it is handed, so a proxy token containing a superuser or tenant-admin role silently confers those permissions on arbitrary forwarded users (custom providers that read authentication data are similarly exposed, while role-name-only providers such as the built-in default are not). Second, independently of the authorization provider, the tenant-admin check for proxied admin REST requests never validates the original principal when the proxy role is itself listed as a tenant admin - behavior present from 2.8.4 in the 2.8.x line, from 2.9.3 in 2.9.x, and from 2.10.1 onward. Fixed versions authorize the proxy role and the original principal separately, use only the original principal's own authentication data, and honor the roles of a forwarded token only when that token actually authenticates as the original principal.
Know when Apache Pulsar gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
Network-reachable and authenticated (PR:L) via valid low-privileged credentials; AC:H reflects the required MultiRolesToken/custom provider or tenant-admin-proxy configuration; full admin capability gives C/I/A High.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
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/.
Executive ViewAI
Apache Pulsar deployments in the 2.8.1-4.0.13 and 4.1.0-4.2.4 ranges contain a privilege-escalation flaw in the proxy-to-broker principal check that can elevate a low-privileged account to the proxy's full entitlement set, including superuser and tenant-admin rights across the broker admin REST API, the functions worker, and the binary protocol. Leadership should care because a single compromised low-privilege credential in a proxy-fronted cluster could translate into full administrative control of messaging infrastructure and the data flowing through it. Exposure is configuration-dependent, limited to clusters using multi-role token or custom data-driven authorization providers, or where a proxy role is registered as a tenant admin.
No vendor-released patch identified at time of analysis. Interim mitigations: disable MultiRolesTokenAuthorizationProvider and any custom data-driven authorization provider in favor of the default provider; remove all proxy roles from tenant-admin lists; issue the proxy a least-privilege token with no superuser or broad role grants; restrict network access to the broker admin REST API, functions worker, and binary protocol ports to proxy hosts only; enable and monitor audit logging of proxy-relayed administrative requests for role expansion or unauthorized tenant operations.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
More in Apache Pulsar
View allUnauthenticated role forgery in Apache Pulsar lets a client present a forged or unsigned JSON Web Token listing arbitrar
Missing authorization in Apache Pulsar's shadow topic feature allows an authenticated tenant administrator to bind a top
Apache Pulsar deployments using the filesystem packages storage provider allow an authenticated user holding packages pe
Truncating a partitioned topic through the Apache Pulsar broker admin REST API succeeds without the caller holding tenan
Apache Pulsar 2.8.0 through 4.2.x deployments that enable package management allow an authenticated user to read package
The deprecated functions connectors endpoints (/admin/v2/functions/connectors and /admin/v3/functions/connectors) in Apa
An authenticated Apache Pulsar client that holds no permission whatsoever on a target topic can read that topic's regist
Authorization flaw in Apache Pulsar's Functions Worker trigger REST endpoint allows an authenticated user who holds func
Authorization bypass in Apache Pulsar (2.8.0 through 4.0.13 and 4.1.0 through 4.2.4) allows an authenticated user holdin
Missing authorization checks in the Apache Pulsar broker admin REST endpoints for non-persistent topics allow an authent
Cross-tenant information disclosure in Apache Pulsar's transaction administration REST API allows any authenticated user
Apache Pulsar's WebSocket service performs an incomplete authorization check when a WebSocket consumer supplies a dead l
Exploit-DB