CVE-2026-105934 in Pulsar
Summary
by MITRE • 10/21/2026
The Apache Pulsar broker admin REST API provides a truncate operation for persistent topics (DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate). Truncating a topic moves all subscription cursors of the topic to the end of the topic and deletes the topic's inactive ledgers. Truncating a non-partitioned topic, or a single partition addressed by its partition name, correctly requires the tenant admin role or the superuser role. When the operation is requested for the name of a partitioned topic, the broker does not apply this tenant admin check to the caller. Instead, it truncates each partition using the broker's own internal admin client, which authenticates with the broker's configured client credentials rather than the caller's identity. Each per-partition truncate request is still checked for the tenant admin role or the superuser role, but against the broker's internal identity instead of the caller. The partitions are therefore truncated only when the broker's configured client role is a superuser or an admin of the target tenant, which is the usual configuration when authorization is enabled.
As a result, when that condition holds, an authenticated user who is not a tenant admin can truncate any partitioned topic on which the user has lookup permission. Caller authentication and lookup permission alone are not sufficient: if the broker's internal identity lacks tenant admin or superuser authorization for the target tenant, the per-partition requests are rejected. With the default authorization provider, lookup permission is granted by produce or consume permission on the topic or its namespace. A user with no permissions on the topic cannot trigger the issue. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
Truncating a partitioned topic this way moves the cursors of all subscriptions on every partition to the end of the topic, so any unacknowledged backlog is skipped and is no longer delivered to consumers. It also deletes eligible older ledgers of each partition regardless of the namespace's configured retention policy, so messages stored in those ledgers can be permanently lost. The ledger currently being written is not deleted by the truncate operation. The issue does not allow reading message contents or changing permissions or configuration, and it does not give access to topics on which the user has no lookup permission.
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.
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 (/admin/v2) to trusted administrative clients.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The Apache Pulsar distributed streaming platform contains a critical authorization bypass vulnerability within its broker administration REST API, specifically affecting the truncate operation for persistent topics. This flaw allows authenticated users who lack tenant administrator privileges or superuser status to execute truncation commands on partitioned topics, provided they possess only basic lookup permissions such as produce or consume rights. The vulnerability stems from an inconsistency in how authorization checks are applied when a user requests the truncation of a multi-partition topic compared to single-partition or non-partitioned topics. When a standard truncate request is made for a specific partition by name, the system correctly validates that the caller holds the necessary administrative roles before proceeding. However, when the operation targets a partitioned topic as a whole entity via its logical name, the broker does not validate the identity of the initiating user against tenant admin or superuser requirements. Instead, it delegates the truncation logic to an internal client mechanism that authenticates using the broker's own configured credentials rather than the caller's identity.
This architectural oversight means that each per-partition truncate request is authorized based on the permissions associated with the broker's internal service account rather than the actual user making the API call. In typical configurations where authorization is enabled, this internal client usually possesses superuser or tenant admin privileges for most tenants to facilitate standard operational tasks. Consequently, any authenticated user who can perform lookups on a partitioned topic can trigger the truncation process across all its partitions without ever being checked for administrative authority. This effectively bypasses the intended access control model of Apache Pulsar, allowing lower-privileged users to execute high-impact administrative operations that should be strictly reserved for tenant administrators or system superusers. The vulnerability is particularly insidious because it relies on a subtle distinction in API endpoint handling and internal client delegation rather than a complete absence of checks.
The operational impact of this unauthorized truncation is severe, leading directly to data loss and service disruption. When the truncate operation executes successfully due to the authorization bypass, all subscription cursors for every partition within the targeted topic are moved to the end of the message stream. This action causes any unacknowledged messages in consumer backlogs to be skipped entirely, meaning they will never be delivered to consumers even if those consumers remain connected and active. Furthermore, the operation deletes inactive ledgers associated with the partitions regardless of the namespace's configured retention policies. Since these older ledgers contain historical message data that has not yet been acknowledged or archived by downstream systems, their deletion results in permanent data loss. The ledger currently being written to is preserved during this process, but all prior history accessible through those deleted ledgers is irretrievably lost for any system relying on Pulsar as a source of truth or audit trail.
From a security classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, reflecting the failure to enforce proper access control checks before allowing privileged actions. In terms of attack vectors, it corresponds to ATT&CK techniques involving privilege escalation through API abuse or improper role assignment validation. The issue does not permit reading message contents directly nor does it allow modification of permissions or system configurations beyond the truncation effect itself. It also respects lookup restrictions in that users without any permission on a topic cannot trigger this behavior. However, given that produce and consume permissions are often granted more broadly than administrative roles to facilitate normal application operations, the attack surface is significant for environments where fine-grained authorization policies have not been strictly enforced at the namespace level.
This vulnerability affects Apache Pulsar versions starting from 2.8.0 up to but excluding 4.0.14 in the 4.0 release line, and from 4.1.0 up to but excluding 4.2.5 in subsequent releases. Users operating on version 4.0.x must upgrade to at least 4.0.14 to resolve this issue, while those on 4.1.x or 4.2.x should upgrade to at least 4.2.5. The currently supported release lines are 4.0.x and 5.0.x, with detailed versioning schedules available through official Apache Pulsar channels. Immediate upgrading is the primary remediation strategy recommended by vendors to eliminate this privilege escalation vector entirely. For environments where immediate patching is not feasible due to operational constraints or testing requirements, a compensating control involves restricting network access to the broker's admin REST API endpoint at /admin/v2 exclusively to trusted administrative clients and internal services that require such privileges. This network-level restriction prevents external users from reaching the vulnerable endpoints altogether, thereby mitigating the risk of unauthorized truncation until an upgrade can be performed.