Apache Pulsar CVE-2026-105931

Exploitation requires three things: the broker must have authentication and authorization enabled (the context in which the authorization gap is reachable), transaction support must be enabled via transactionCoordinatorEnabled (which is disabled by default), and the attacker must hold a valid authenticated credential - though it can be an account with zero granted permissions. Limiting factors: only the read endpoints under /admin/v3/transactions are affected (state-changing abort/scale endpoints still enforce super-user access); exposure is confined to transaction metadata and statistics, not message contents, configuration, or transaction modification. When transaction support is disabled the only residual effect is that one endpoint's error response can reveal whether a named topic exists in another tenant. Restricting network access to the broker's admin HTTP endpoints to trusted administrative clients further limits realistic exposure.

This is a genuinely low-priority, low-severity issue, and the available signals agree rather than conflict. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) and score of 2.3 indicate a network-reachable but authenticated (PR:L) flaw whose only impact is low confidentiality (VC:L) with no integrity or availability effect (VI:N/VA:N) and no subsequent-system/scope impact (SC:N/SI:N/SA:N). The CWE-862 (Missing Authorization) classification is consistent with the description: authenticated callers bypass tenant/namespace/topic authorization on read-only transaction endpoints. The AT:P (attack requirement) correctly reflects that disclosure only occurs when transactionCoordinatorEnabled is turned on, which is NOT the default. No EPSS score was provided in the input; no CISA KEV listing is present (KEV=NO); and no public exploit is indicated (POC=NO), so there is no public exploit identified at time of analysis. The impact ceiling is low: only transaction metadata and statistics leak across tenants - not message contents, and no ability to modify or abort transactions or alter configuration. Net assessment: a real but minor multi-tenant information-disclosure weakness, meaningful mainly to shared/multi-tenant Pulsar operators with transactions enabled, and not an urgent patch for most deployments.

In a multi-tenant Apache Pulsar cluster with authentication/authorization and transaction support enabled, an attacker who holds any valid broker credential - even an account granted no permissions - issues HTTP GET requests to the /admin/v3/transactions read endpoints. The broker returns transaction coordinator listings (including broker service URLs), transaction metadata (involved topic/subscription names and the principal that opened each transaction), and buffer/acknowledgement statistics belonging to other tenants, enabling cross-tenant reconnaissance. No public exploit code is identified at time of analysis; exploitation is trivial scripting against the documented REST API.