Key points
- CVE-2026-105937 affects Apache Pulsar versions 3.0.0 through 4.0.13 and 4.1.0 through 4.2.4.
- The flaw allows users to bind shadow topics to source topics in other tenants without permission.
- Patches are available in versions 4.0.14 and 4.2.5, which disable shadow topics by default.
Apache Pulsar releases 4.0.14 and 4.2.5 address a high-severity authorization flaw identified as CVE-2026-105937. The issue affects versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Users of these affected releases must upgrade to the patched versions or newer to mitigate the risk. The Apache Software Foundation has confirmed that versions 2.x are not affected because they lack the shadow topic implementation entirely.
In plain English
The vulnerability exists in how Apache Pulsar handles shadow topics, which are topics that read messages from a source topic. When creating or updating a topic, the broker checks permissions for the new topic but fails to check permissions for the source topic specified in the configuration. This allows an authenticated user with tenant admin rights to link their topic to any persistent topic in another tenant, bypassing standard authorization controls.
The background
An attacker can consume retained messages from the unauthorized source topic using only permissions on their own shadow topic. This exposure is limited to messages still retained in the source ledgers; client-side encryption protects data if keys are not compromised. Furthermore, the shadow topic’s managed ledger can permanently delete source topic data from storage, including unacknowledged messages, regardless of the source topic’s retention policies.
What changes now
In the fixed versions, shadow topics are disabled by default and controlled by a new broker setting. The broker rejects creating shadow topics or setting the source property when this feature is off. Deployments relying on shadow topics must explicitly enable the feature in the broker configuration after upgrading. Binding a shadow topic to a different tenant now requires a superuser role, and the system prevents shadow topics from deleting source data.
Who needs to act first
Teams should prioritize updating systems that expose Apache Pulsar to multiple tenants or external users. Before applying the upgrade, verify that existing shadow topic configurations are documented and that the new broker settings are prepared. Test the patch in a non-production environment to ensure that legitimate shadow topic workflows continue to function correctly after enabling the feature. Monitor logs for any unexpected authorization failures during the rollout to catch misconfigurations early.
What to do and how to stay safe: Apache Pulsar
- Review your Apache Pulsar version against the affected ranges and schedule an upgrade to 4.0.14 or 4.2.5.
- Audit current shadow topic configurations to identify any cross-tenant bindings that may now require superuser permissions.
- Restrict the tenant admin role to trusted principals only if you cannot upgrade immediately to reduce exposure.
- Monitor broker logs for errors related to shadow topic loading after upgrading, as the feature is disabled by default.
Step-by-step guide: Emergency Patching: How to Fix Critical Flaws Without Breaking Systems
General security guidance from the Patch Review newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does this vulnerability affect Apache Pulsar 2.x?
No, Apache Pulsar 2.x releases do not contain the shadow topic implementation and are not affected by this issue.
Can a user delete data from another tenant's topic?
Yes, the shadow topic’s managed ledger can permanently delete the source topic's ledger data from BookKeeper and tiered storage.
Are messages protected by encryption at risk?
Messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys, limiting the impact.
