CVE-2026-105938 in Pulsar
Summary
by MITRE • 10/21/2026
Apache Pulsar namespaces can restrict which roles may use a subscription, either with the Prefix subscription authentication mode, which requires a subscription name to start with the role name, or by granting permission on a subscription to specific roles. Topic-level subscription operations, such as consuming, skipping messages, resetting a cursor or deleting a subscription, apply these subscription policies. Several admin REST API operations that act on subscriptions did not apply them:
- the namespace-level and bundle-level clear backlog operations, both for a named subscription and for all subscriptions; - the namespace-level and bundle-level unsubscribe operations; - the topic-level operation that expires messages for all subscriptions of a topic.
With the default authorization provider, the namespace-level operations require only consume permission granted on the namespace, and the expire-all operation requires only consume permission on the topic. As a result, when authentication and authorization are enabled and a namespace uses the Prefix subscription authentication mode or subscription permissions, an authenticated user with such consume permission can clear the backlog of, expire messages of, or delete a subscription that the policies would deny to that user. Tenant admin or superuser access is not required. The clear backlog operations can also be applied to the cursors used for geo-replication, so that messages not yet replicated to a remote cluster are skipped. Deployments that do not configure the Prefix subscription authentication mode or subscription permissions (the defaults) are not affected by this bypass, because consume permission on the namespace or topic already allows these operations there. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
The impact is on the integrity of subscription state. Clearing or expiring the backlog moves the subscription's cursor forward, so unacknowledged messages are no longer delivered to the subscription's consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespace's retention policy keeps them. The issue does not allow reading message contents, changing permissions or policies, or accessing other namespaces, and it does not affect the availability of the broker.
In fixed versions, the namespace-level and bundle-level operations for a named subscription apply the subscription policies to that subscription, and the operations for all subscriptions, when requested by a user who is not a tenant admin or superuser, only act on the subscriptions that the user may access. Clearing the backlog of geo-replication cursors requires tenant admin or superuser access. Topic-level subscription operations apply the subscription policies for all types of authentication data, including that of the anonymous user role.
This issue affects Apache Pulsar versions from 2.8.0 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.
All brokers in a cluster must be upgraded before relying on the namespace-level restrictions, because brokers that have not been upgraded do not apply them when they receive the internal per-bundle requests.
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 cannot upgrade immediately can reduce exposure by restricting network access to the broker's admin REST API to trusted administrative clients.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
Apache Pulsar, a distributed pub-sub messaging system, implements granular authorization controls that allow administrators to restrict which roles may interact with specific subscriptions within namespaces. These restrictions are typically enforced through two primary mechanisms: Prefix subscription authentication mode, where subscription names must correspond to role identifiers, or explicit permission grants on individual subscriptions for designated roles. Topic-level operations such as consuming messages, skipping message cursors, resetting cursor positions, and deleting subscriptions are designed to respect these policies. However, a critical authorization bypass exists within several administrative REST API endpoints that manage backlog clearing, unsubscription, and message expiration across entire namespaces or bundles rather than specific topics. This vulnerability allows authenticated users with basic consume permissions on a namespace or topic to perform actions that should be restricted by subscription-level policies, effectively circumventing the intended access controls without requiring tenant administrator or superuser privileges.
The technical flaw stems from an inconsistency in how authorization checks are applied across different operational scopes within the Apache Pulsar architecture. While standard topic-level operations correctly validate subscription permissions before execution, namespace-level and bundle-level administrative functions such as clear backlog for all subscriptions, unsubscribe for all subscriptions, and expire messages for all subscriptions fail to enforce these granular restrictions when using the default authorization provider. Consequently, an authenticated user who possesses only consume permission on a namespace can invoke API calls that clear backlogs or delete subscriptions belonging to roles they are not authorized to access. Similarly, users with topic-level consume permissions can trigger message expiration operations across all subscriptions in a topic, regardless of whether those subscriptions belong to unauthorized roles. This bypass is particularly dangerous because it operates under the assumption that broad namespace or topic permissions imply full control over associated subscription states, which contradicts the principle of least privilege enforced by detailed subscription policies.
The operational impact of this vulnerability centers on the integrity and availability of message delivery systems rather than data confidentiality or system uptime. By clearing backlogs or expiring messages for unauthorized subscriptions, an attacker can cause unacknowledged messages to be permanently lost if no other subscription retains them or if retention policies do not preserve them. This results in a denial of service for legitimate consumers associated with those restricted subscriptions, as their message queues are emptied without authorization. Furthermore, the clear backlog operation affects cursors used for geo-replication; exploiting this flaw allows an attacker to skip messages that have not yet been replicated to remote clusters, potentially leading to data inconsistency across distributed deployments. The vulnerability does not permit reading sensitive message contents, modifying system permissions or policies, accessing other namespaces, or causing broker unavailability, but it significantly undermines trust in the integrity of subscription state management and inter-cluster replication consistency.
This issue is classified under CWE-269 Improper Privilege Management as it involves a user obtaining access to resources beyond their authorized scope through an authorization bypass. In terms of attack vectors, it aligns with ATT&CK techniques related to resource hijacking or data manipulation via API abuse, specifically targeting the integrity component rather than confidentiality or availability in the traditional sense. The vulnerability affects Apache Pulsar versions from 2.8.0 up to but not including 4.0.14, and from 4.1.0 up to but not including 4.2.5. Deployments utilizing custom authorization providers may experience different impacts depending on their specific implementation logic, though the default provider is confirmed vulnerable. Organizations running affected versions must prioritize remediation due to the potential for significant data loss in production environments relying on strict subscription-based access controls and geo-replication integrity.
Mitigation strategies primarily involve upgrading Apache Pulsar components to patched releases that enforce consistent authorization checks across all administrative operations. Users of version 4.0.x should upgrade to at least 4.0.14, while users of versions 4.1.x and 4.2.x must upgrade to at least 4.2.5. It is critical that all brokers within a cluster are upgraded simultaneously or sequentially before relying on the new namespace-level restrictions, as unpatched brokers will not apply these checks when receiving internal per-bundle requests from patched peers, potentially leaving gaps in enforcement during mixed-version periods. For organizations unable to upgrade immediately due to operational constraints, reducing exposure involves restricting network access to the broker's admin REST API exclusively to trusted administrative clients with strong authentication and authorization controls. This limits the attack surface by preventing unauthorized users from reaching the vulnerable endpoints altogether until a permanent fix can be deployed according to the supported release schedule available in official Apache Pulsar documentation.