EUVD-2026-107422
GHSA-2x72-7fcr-36h8
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconReach broker HTTP/WebSocket endpoint
-
DeliveryCraft unsigned JWT with superUser role claim
-
ExploitSubmit request with forged bearer token
-
InstallAuthentication falls back to anonymous role
-
C2Provider trusts unverified token roles
-
ExecuteAuthorized as super-user
-
ImpactRead/modify tenants, topics, broker config
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | Exploitable only when ALL of the following hold: the broker uses MultiRolesTokenAuthorizationProvider as its authorizationProvider, authentication and authorization are enabled, and anonymousUserRole is set to a non-empty value. For broker HTTP endpoints (e.g. the admin REST API) the request must not name an authentication method and strictAuthMethod must be false (the default where that setting exists); the WebSocket API path does not enforce strictAuthMethod at all. Limiting factors that reduce real-world exposure: deployments using the default PulsarAuthorizationProvider or any other authorization provider are NOT affected, deployments with anonymousUserRole unset (the default) are NOT affected, successfully authenticated requests with valid tokens are NOT affected, and connections using the Pulsar binary protocol are NOT affected because the broker discards client auth data for anonymous-role connections. Mitigations without upgrading: remove anonymousUserRole from broker and WebSocket configs, or restrict network access to these HTTP endpoints to trusted clients. |
| Impact | This is a genuine high-priority issue in affected deployments, but its real-world reach is gated by a specific non-default configuration rather than being universally exploitable. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) correctly captures network reach with no authentication (PR:N), while AT:P (attack requirements present) reflects that exploitation depends on a particular broker configuration - MultiRolesTokenAuthorizationProvider plus a non-empty anonymousUserRole plus the HTTP fallback being permitted (strictAuthMethod=false, the default where available; WebSocket does not enforce it). CWE-347 (improper signature verification) matches the root cause precisely: the provider parsed JWT claims with the signature stripped and trusted roles it never verified, yielding potential super-user access to tenants, namespaces, topics, permissions and broker configuration - a full confidentiality/integrity/availability compromise (VC:H/VI:H/VA:H), not merely information disclosure. No EPSS score, KEV listing, or public POC was provided in the input; exploitation status is therefore 'no public exploit identified at time of analysis' and should not be conflated with active exploitation. The 9.2 base score overstates universal risk because the vulnerable code path is off by default (anonymousUserRole unset, and the default PulsarAuthorizationProvider is unaffected); for deployments NOT using that combination this is effectively not exploitable, so prioritization should be driven by configuration auditing rather than the raw score alone. |
| Exploit ScenarioDerived | An attacker who can reach a Pulsar broker's admin REST API or WebSocket endpoint sends an HTTP request carrying an Authorization bearer header containing a forged, unsigned JWT whose role claim lists a role present in superUserRoles. Because authentication falls back to the anonymous user role but the authorization provider still reads and trusts the attacker-supplied token, the request is authorized as a super-user, letting the attacker read and modify tenants, namespaces, topics, permissions and broker configuration with no valid credentials. No public exploit was identified in the provided data, though the attack is low-complexity once the required configuration is present. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Unauthenticated role forgery in Apache Pulsar lets a client present a forged or unsigned JSON Web Token listing arbitrary roles and have those roles honored when the broker uses MultiRolesTokenAuthorizationProvider alongside a non-empty anonymousUserRole. The flaw is reachable over the broker's HTTP surfaces, including the admin REST API and the WebSocket API, where failed credentials can fall back to the anonymous role while the original Authorization header is retained and later trusted without signature verification; an attacker who names a role configured in superUserRoles can obtain super-user access to tenants, namespaces, topics, permissions and broker configuration. Only deployments combining MultiRolesTokenAuthorizationProvider with a non-empty anonymousUserRole and the fallback conditions are exposed, while installations using the default PulsarAuthorizationProvider, another authorization provider, or an unset anonymousUserRole are unaffected. Vendor-released patch: 4.0.14 and 4.2.5; no public exploit identified at time of analysis, and exploitation also requires the specific non-default configuration described.
RemediationAI
Vendor-released patch: upgrade to Apache Pulsar 4.0.14 or later on the 4.0.x line, or to 4.2.5 or later for 4.1.x and 4.2.x users; supported release lines are 4.0.x and 5.0.x per the Apache release policy at https://pulsar.apache.org/contribute/release-policy/, and versions older than those listed should move to the patched releases or newer. Where an immediate upgrade is not possible, remove the anonymousUserRole setting from both the broker and WebSocket service configurations so the anonymous fallback that exposes the retained Authorization header no longer occurs, accepting that clients relying on anonymous access will be rejected, or restrict network access to the broker's HTTP and WebSocket endpoints to trusted clients, which reduces exposure but does not fix the underlying signature-verification flaw for those still able to reach the endpoints. Also consider setting strictAuthMethod to true on HTTP endpoints where the setting exists as a defense-in-depth measure, though it does not cover the WebSocket path. Note that patched brokers fail to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider, so ensure a token authentication provider is configured before upgrading. Advisory and reference material: https://pulsar.apache.org/security/CVE-2026-105869/ and https://lists.apache.org/thread.html/lf36z1tlcsokp4gv97obkdjtt74ngmrw.
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
The root cause is CWE-347, Improper Verification of Cryptographic Signature, in Apache Pulsar's MultiRolesTokenAuthorizationProvider. JWT-based token authentication in Pulsar normally has the configured token authentication provider validate the token's signature with its configured keys and validation settings before any authorization decision; MultiRolesTokenAuthorizationProvider instead parsed the token claims with the signature stripped and assumed authentication had already been performed. When authentication and authorization are enabled and anonymousUserRole is set to a non-empty value, certain broker HTTP requests whose credentials fail authentication are not rejected but are handled as anonymous-role requests, and the retained authentication data still carries the request's Authorization header. For broker HTTP endpoints such as the admin REST API this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false, which is the default where the setting exists; the WebSocket API path does not enforce strictAuthMethod at all. In those paths the provider read the bearer token from the retained header without verifying its signature and authorized the request using the token's role claim, so an attacker-supplied unsigned token could assert arbitrary roles, including one listed in superUserRoles. Deployments on the default PulsarAuthorizationProvider or any other authorization provider are not affected, requests that authenticate successfully with a valid token are not affected because the token read is the one authentication verified, and the Pulsar binary protocol is not affected because the broker does not keep client authentication data for connections assigned to the anonymous user role. The affected software is tracked under CPE cpe:2.3:a:apache_software_foundation:apache_pulsar, and fixed releases make the provider obtain roles only from tokens the configured token authentication provider has verified, restrict anonymous-role HTTP requests to that role, prevent invalid tokens from supplying extra WebSocket roles, and fail broker startup when MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.
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:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Network-reachable and unauthenticated (AV:N/PR:N), but the non-default anonymousUserRole + MultiRolesTokenAuthorizationProvider precondition maps to AC:H; super-user access gives full C/I/A impact within the broker's authority (S:U).
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
Apache Pulsar's MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token's claims with the signature removed and trusted that authentication had already checked it.
When authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker's HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request's Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token's role claim.
As a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.
Deployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.
In fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.
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/.
Users who cannot upgrade immediately can remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients.
Articles & Coverage 1
Executive ViewAI
Apache Pulsar brokers configured with MultiRolesTokenAuthorizationProvider alongside a non-empty anonymousUserRole can be tricked into honoring forged or unsigned tokens, letting an outside party assume any role named in that token - including a configured super-user - over the organization's messaging tenants, namespaces, topics and broker configuration. Exposure is configuration-dependent rather than universal, but where it applies the blast radius is the entire Pulsar estate, which typically underpins event-driven and data-pipeline workloads. Leadership should care because compromise of a broker's super-user role can silently redirect, read or destroy business data flows and alter platform-wide settings with no credential theft required.
Apply vendor patch (upgrade to Apache Pulsar 4.0.14). If the upgrade cannot be completed immediately, unset anonymousUserRole or replace MultiRolesTokenAuthorizationProvider with the default PulsarAuthorizationProvider, since deployments without that configuration combination are unaffected.
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Apache Pulsar
View allMissing 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
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 fu
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