CVE-2026-105933 in Pulsar
Summary
by MITRE • 10/21/2026
Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.
When the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.
While the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.
The condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.
In fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.
This issue affects Apache Pulsar versions from 1.22.0-incubating 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 rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing "isEncryptionRequired will be set to false" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/21/2026
Apache Pulsar provides a namespace-level policy called encryption_required which allows administrators to mandate end-to-end message encryption for all topics within a specific namespace. This security control is designed to ensure that no unencrypted data persists in the system, thereby protecting sensitive information from unauthorized access or interception during storage and transmission. When this policy is enabled, the broker is expected to reject any messages published without proper cryptographic protection. However, a critical flaw exists in the topic initialization logic where transient or persistent errors during metadata store reads or policy loading can lead to a silent degradation of security controls. Instead of failing the operation and preventing the topic from becoming active with weak security postures, the broker logs a warning but proceeds to load the topic while disabling the encryption requirement for that specific topic. This behavior effectively bypasses the administrative intent to enforce end-to-end encryption, creating a significant gap in data protection mechanisms.
The technical root cause lies in how the broker handles initialization failures during the loading of persistent topics. During this process, the system reads namespace policies and topic-level configurations. If any step fails due to metadata store errors or policy retrieval issues, the current implementation chooses to degrade gracefully by disabling the encryption requirement rather than aborting the load. Consequently, the topic is served with encryption_required set to false, even though the overarching namespace policy mandates it. This flaw applies not only to new producers but also affects existing connections that were established before the failure occurred. While messages published while the system was in this compromised state remain encrypted if the producer explicitly encrypts them, authenticated clients with produce permissions can choose to send unencrypted data, which the broker will accept and store without raising an error or alerting administrators beyond a standard warning log entry.
The operational impact of this vulnerability is severe because it undermines compliance requirements for data encryption at rest and in transit. Since the condition persists across topic reloads triggered by events such as namespace bundle reassignments, unloads, or broker restarts, the security gap can remain open indefinitely if the underlying initialization failure is not resolved. The issue is particularly insidious because the broker reports the topic load as successful, and the status of the encryption requirement is not visible in standard topic statistics. This lack of visibility makes it difficult for operators to detect that their data protection policies are being silently bypassed. Furthermore, updating namespace policies does not immediately restore enforcement on already loaded topics; the change only takes effect after a subsequent reload, which may never occur if the initialization error persists, leaving systems vulnerable until manual intervention or resolution of the root cause occurs.
This vulnerability affects Apache Pulsar versions from 1.22.0-incubating up to but not including 4.0.14, and from version 4.1.0 up to but not including 4.2.5. The flaw aligns with CWE-693, which describes Protection Mechanism Failure, as the system fails to enforce a security control due to an internal error handling logic that prioritizes availability over integrity of policy enforcement. From an ATT&CK perspective, this could be exploited by an insider threat or compromised account to bypass data exfiltration controls, falling under techniques related to Defense Evasion and potentially Data Exfiltration if unencrypted sensitive data is transmitted outside the protected perimeter. The lack of explicit alerts for encryption violations allows attackers to operate with reduced risk of detection compared to systems that strictly fail on policy violation.
To mitigate this vulnerability, users operating affected versions must upgrade to Apache Pulsar 4.0.14 or later for the 4.0.x branch, and version 4.2.5 or later for the 4.1.x and 4.2.x branches. The currently supported release lines are 4.0.x and 5.0.x, with detailed support schedules available in official documentation. For organizations that cannot immediately upgrade due to operational constraints, a temporary mitigation strategy involves monitoring broker logs for warnings indicating that encryption requirements have been disabled. Administrators should identify the specific warning messages which vary slightly between releases but generally contain phrases like isEncryptionRequired will be set to false. Upon detecting such warnings, operators must resolve the underlying metadata or policy loading failures and then manually reload the affected topics to restore enforcement of the encryption policies until a permanent upgrade can be performed.