Apache Pulsar EUVD-2026-107471

Exploitation requires: (1) a valid authenticated Pulsar identity (PR:L) - not anonymous; (2) lookup permission on the target topic, which under the default authorization provider is granted by produce or consume permission on the topic or its namespace, so a user with no permissions cannot trigger it; (3) the target must be a PARTITIONED topic requested by its partitioned-topic name - non-partitioned topics and individual partitions addressed by partition name are correctly checked and not affected; and (4) the broker's own configured internal client role must be a superuser or an admin of the target tenant (the usual configuration when authorization is enabled) - if the broker's internal identity lacks that role, the per-partition truncate requests are rejected and exploitation fails. This analysis assumes the default authorization provider; custom providers may differ. Limiting factors for defenders: the caller must be authenticated and already permissioned on the topic, only partitioned topics are affected, no confidentiality impact, and exposure is reduced by restricting network access to the broker admin REST API (/admin/v2) to trusted administrative clients.

This is a genuine but bounded-impact issue rather than a top-tier emergency. The Apache-assigned CVSS 4.0 base score is 7.2 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N): network-reachable via the admin REST API, low attack complexity, but requiring an authenticated principal (PR:L) rather than an anonymous attacker. Impact is confined to integrity and availability (VI:H/VA:H) - permanent message/data loss and skipped backlog - with no confidentiality exposure (VC:N) and no scope change (SC:N), so it is a destructive/denial-of-data flaw, not RCE or information disclosure. No EPSS probability was provided in the input, there is no CISA KEV listing, and no public exploit code is referenced - so there is no public exploit identified at time of analysis and no evidence of active exploitation. Exploitation is further gated by two real conditions (the caller must already hold lookup/produce/consume permission on the target, and the broker's own internal client identity must be a superuser or tenant admin - the common configuration when authorization is enabled), which keeps this below the priority of an unauthenticated internet-facing bug. Net assessment: a real priority for multi-tenant Pulsar operators where lower-privileged tenants share brokers, but materially de-rated by the authentication and permission prerequisites and the absence of exploitation signals. Missing signal to note: EPSS is absent from the provided data and cannot be weighed.

In a multi-tenant Pulsar deployment with authorization enabled, an authenticated user who holds only produce/consume (and thus lookup) permission on a partitioned topic - but is not a tenant admin - sends DELETE /admin/v2/persistent/{tenant}/{namespace}/{topic}/truncate for that partitioned topic name. Because the broker omits the tenant-admin check for partitioned-topic names and re-issues each per-partition truncate under its own superuser/admin credentials, every partition is truncated: subscription cursors jump to the topic end and eligible older ledgers are deleted, permanently discarding retained messages and unacknowledged backlog. No public exploit identified at time of analysis; the attack uses only a standard authenticated admin-API HTTP call.