CVE-2026-105931 in Pulsar
Summary
by MITRE • 10/21/2026
The Apache Pulsar broker exposes a transaction administration REST API under /admin/v3/transactions. When authentication and authorization are enabled, most of the read endpoints of this API verify only that the request is authenticated and that the broker serves the requested topic or transaction coordinator. They do not check whether the caller is permitted to access the tenant, namespace or topic whose data is returned. The endpoints that modify state, which abort a transaction or scale the transaction coordinators, correctly require super-user access and are not affected.
As a result, any authenticated user, including one that has been granted no permissions, can read transaction coordinator and transaction information belonging to other tenants. This includes the list of transaction coordinators with the broker service URLs that serve them, transaction coordinator statistics and internal statistics, transaction metadata including the names of the topics and subscriptions a transaction involves and the principal that opened it, the list of long-running transactions on a transaction coordinator, transaction buffer and pending acknowledgement statistics and internal statistics for any topic and subscription, and whether a given message position of a subscription is currently held in a pending transactional acknowledgement.
The disclosure of transaction metadata and statistics can only occur when transaction support is enabled in the broker (transactionCoordinatorEnabled, which is disabled by default). When transaction support is disabled, these endpoints return no transaction data; the only residual effect is that one endpoint's error response can reveal whether a named topic exists in another tenant.
The impact is limited to disclosure of transaction-related metadata and statistics across tenant boundaries. The issue does not allow reading message contents, modifying or aborting transactions, or changing any configuration.
This issue affects Apache Pulsar versions from 2.8.0 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 and do not use Pulsar transactions should keep transaction support disabled. Where transactions are required, restricting network access to the broker's admin HTTP endpoints to trusted administrative clients reduces the exposure.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The Apache Pulsar distributed messaging system contains a critical authorization bypass vulnerability within its transaction administration REST API, specifically located at the /admin/v3/transactions endpoint path. This flaw allows authenticated users who lack specific permissions for certain tenants, namespaces, or topics to access sensitive internal data belonging to other tenants in a multi-tenant environment. The vulnerability stems from an incomplete implementation of access control checks on read-only endpoints within this API section. While the system correctly enforces super-user privileges for state-modifying operations such as aborting transactions or scaling transaction coordinators, it fails to validate whether the requesting user has explicit authorization to view data associated with specific tenant resources when retrieving static information about transaction coordinators and their states.
From a technical perspective, this issue represents an insecure direct object reference combined with broken access control mechanisms. When authentication is enabled but fine-grained authorization for tenants or topics is not strictly enforced on these read endpoints, the broker serves as an unauthorized data conduit. The vulnerability specifically impacts scenarios where transaction support is explicitly enabled via the transactionCoordinatorEnabled configuration flag, which remains disabled by default in standard deployments. Consequently, any authenticated principal can query internal statistics and metadata that reveal operational details of other tenants' transactions without possessing the requisite administrative or topic-level permissions. This behavior violates the principle of least privilege and fails to enforce proper isolation boundaries between multi-tenant workloads within the same Pulsar cluster.
The operational impact involves the disclosure of extensive transaction-related metadata across tenant boundaries, which can facilitate further reconnaissance attacks against other tenants sharing the infrastructure. Exposed information includes the list of active transaction coordinators along with their service URLs, internal statistics regarding coordinator performance and health, and detailed transaction metadata such as the names of topics and subscriptions involved in ongoing transactions. Additionally, attackers can identify the principal identity that initiated specific transactions, view lists of long-running transactions on a given coordinator, and access buffer or pending acknowledgement statistics for any topic and subscription. A particularly sensitive capability is the ability to determine whether a specific message position within a subscription is currently held by a pending transactional acknowledgment, which may aid in timing attacks or inference-based data leakage strategies.
This vulnerability does not permit the reading of actual message payloads, nor does it allow modification, abortion, or creation of transactions, thereby limiting the direct impact to information disclosure rather than integrity compromise or service disruption. However, the exposure of internal architecture details and transaction states can significantly aid adversaries in mapping out the multi-tenant environment, identifying high-value targets based on transaction activity patterns, and potentially correlating user identities with specific business processes through topic names and subscription metadata. The risk is further compounded by the fact that even when transactions are disabled, a residual side effect exists where error responses from one endpoint can reveal the existence of topics belonging to other tenants, providing additional reconnaissance vectors for attackers attempting to enumerate resources within the cluster.
In terms of industry standard classifications, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as the system fails to enforce proper access controls on sensitive administrative endpoints. From an ATT&CK perspective, it facilitates Discovery techniques such as T1046 Network Service Scanning or T1537 Transfer Data to Cloud Account if combined with other exfiltration methods, although primarily it serves as a mechanism for internal reconnaissance and information gathering within the network perimeter. The lack of tenant-level isolation in read operations creates an environment where lateral movement and privilege escalation become more feasible by providing attackers with contextual intelligence about the broader system architecture and active workloads.
To mitigate this risk, organizations running affected versions must upgrade to Apache Pulsar 4.0.14 or later for the 4.0.x branch, or to version 4.2.5 or later for the 4.1.x and 4.2.x branches. For users operating on older unsupported lines such as those prior to 2.8.0, upgrading to any currently supported release line including 4.0.x or 5.0.x is strongly recommended in accordance with the official Apache Pulsar release policy. Immediate remediation should be prioritized for environments where transaction support is enabled and multi-tenancy is utilized, as these configurations present the highest exposure surface for this specific authorization bypass flaw.
For deployments that cannot immediately upgrade to a patched version due to operational constraints or compatibility requirements, several compensating controls can reduce the attack surface. The most effective mitigation involves disabling transaction support entirely by setting the transactionCoordinatorEnabled flag to false in the broker configuration, which prevents the vulnerable endpoints from returning any transaction data and limits exposure to only minor metadata leakage via error messages. Additionally, restricting network access to the broker's admin HTTP endpoints exclusively to trusted administrative clients through firewall rules or reverse proxy configurations can prevent unauthorized authenticated users from reaching these API paths. Implementing strict identity and access management policies that ensure all tenants have clearly defined permissions may also help in detecting anomalous access patterns indicative of exploitation attempts against this vulnerability.