Apache Pulsar CVE-2026-105926

Exploitable ONLY in Apache Pulsar deployments that have both authentication AND authorization enabled; deployments without authz are out of scope. The attacker must be an authenticated client that holds no permission on the target topic, namespace, or tenant, and must use a client that implements the binary protocol directly - the standard Pulsar client first performs an authorized topic lookup, which masks the missing check. GetSchema disclosure applies from version 2.2.0; GetOrCreateSchema registration applies from 2.5.0. Limiting factors: only schema metadata (record field names/types) is exposed - message payloads are never disclosed; the integrity/availability impact is bounded by the topic's existing schema compatibility and schema auto-update policies, and a resulting outage is administratively correctable; and this analysis assumes the default authorization provider, so custom providers may behave differently. REST API schema endpoints are not affected.

This is a genuine-but-moderate issue, not a drop-everything priority. CVSS 4.0 base score is 5.3 (Medium) with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:L - network reachable and low complexity, but PR:L confirms the attacker must already hold valid broker credentials, and all impacts are rated Low. No EPSS score was provided, the CVE is not on CISA KEV, and no public exploit was supplied, so exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent: a missing-authorization flaw (CWE-862) that requires authentication, affects only schema metadata (not message payloads), and whose worst outcome is a correctable denial of service via an incompatible schema registration. A practical limiter not captured by CVSS is that the standard Pulsar client performs an authorized topic lookup before issuing these commands, so exploitation requires a custom client that speaks the binary protocol directly - this reduces real-world opportunistic risk. The main risk is to multi-tenant Pulsar deployments where tenant isolation is a security boundary; there, cross-tenant schema disclosure and the ability to break another tenant's producers/consumers is meaningful despite the Medium score. Note the vendor set SC:N (no scope change), yet the impact crosses namespace/tenant boundaries, which some analysts would score as a scope change - this is a judgment call worth noting rather than a data conflict.

An attacker who holds any valid broker credential (for example a low-privilege tenant user) connects to the Pulsar broker using a custom client that implements the binary protocol directly, skipping the authorized topic lookup the standard client normally performs. They issue GetSchema against a topic in a different tenant to read its schema field names and types, then issue GetOrCreateSchema to register a new, incompatible schema version on that topic, causing the legitimate producers and consumers to fail until an administrator restores the schema. No public exploit code is identified at time of analysis.