CVE-2026-105926 in Pulsar
Summary
by MITRE • 10/21/2026
The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker's other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected.
An authenticated client without any permission on the target topic, namespace or tenant could use these commands to:
- read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed. - register a new schema version on an existing topic in another namespace or tenant. The topic's schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator.
The standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first.
This issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.
This issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.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/.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2026
Apache Pulsar, a distributed pub-sub messaging platform, contains an authorization bypass vulnerability in its binary protocol implementation affecting the GetSchema and GetOrCreateSchema commands. This flaw stems from insufficient access control checks within the broker logic for these specific operations. While standard topic management commands such as creating producers or consumers correctly verify that the authenticated client possesses appropriate permissions on the target resource, the schema-related endpoints failed to perform this critical authorization step. The vulnerability is relevant only in deployments where both authentication and authorization are enabled using a default or custom authorization provider. In affected versions, any authenticated user can interact with these commands regardless of their actual permission scope regarding the specific topic, namespace, or tenant involved.
The technical flaw allows an attacker to exploit two distinct attack vectors depending on which command is invoked. First, by issuing the GetSchema command, a malicious actor without explicit permissions can retrieve the schema definition registered for any topic in another namespace or tenant. This action results in information disclosure of structural metadata such as record field names and data types. Although message payloads remain protected and are not exposed through this vector, the leakage of schema definitions can aid attackers in understanding system architecture and potentially crafting more targeted attacks against downstream consumers that rely on strict type checking. Second, by issuing the GetOrCreateSchema command, an unauthorized client can register a new schema version for an existing topic outside their permitted scope. While standard compatibility checks and auto-update policies still apply during registration, this action allows an attacker to introduce incompatible schemas into topics they do not control.
The operational impact of these vulnerabilities is primarily focused on availability and integrity rather than confidentiality or direct data exfiltration. The information disclosure via GetSchema provides attackers with valuable intelligence about the internal structure of distributed systems, which can facilitate further reconnaissance efforts aligned with ATT&CK techniques such as T1087 Account Discovery or T1592 Gather Victim Host Information. More critically, the ability to register new schema versions via GetOrCreateSchema poses a significant risk to service availability. Since Pulsar consumers often enforce strict schema compatibility checks, injecting an incompatible schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors. This effectively creates a denial-of-service condition for applications relying on that specific data stream until an administrator manually intervenes to correct or revert the schema configuration.
This vulnerability is not observable when using the standard Apache Pulsar client libraries because they implement additional logic that performs authorized topic lookups before sending binary protocol commands. The flaw specifically impacts clients that interact directly with the Pulsar binary protocol without performing these preliminary authorization checks. This distinction highlights a common pattern in distributed systems where high-level abstractions may inadvertently patch lower-level security gaps, leaving direct API users exposed to privilege escalation and unauthorized access issues.
The vulnerability affects Apache Pulsar versions starting from 2.2.0 up to but not including 4.0.14, as well as versions 4.1.0 through 4.1.3 and 4.2.0 before 4.2.5. The GetSchema command has been vulnerable since version 2.2.0, while the GetOrCreateSchema command was introduced with vulnerabilities in version 2.5.0. To mitigate this risk, organizations must upgrade to patched versions that enforce proper authorization checks. Specifically, after the fix is applied, the broker requires lookup permission on the topic for executing GetSchema and produce permission on the topic for executing GetOrCreateSchema. Users operating within the supported release lines should ensure they are running at least version 4.0.14 if using the 4.0.x branch or at least version 4.2.5 if using the 4.1.x or 4.2.x branches. For environments utilizing custom authorization providers, administrators should verify that their specific provider implementations also enforce these permission checks correctly to ensure comprehensive protection against this class of vulnerability.