Apache Pulsar broker REST API endpoints that manage entry filter policies for non‑persistent topics lack the required authorization check. When authentication and authorization are enabled, an authenticated user who has produce or consume rights but no policy‑management privileges can read, replace, or delete the entry filter policy for a non‑persistent topic. This allows the attacker to alter which entry filters are applied during message dispatch, potentially causing messages to be withheld or mis‑filtered. The flaw does not enable arbitrary code execution, message payload disclosure, or installation of new entry filters; it only permits modification of existing, pre‑installed filter policies.

Apache Pulsar versions 3.3.0 up to before 4.0.14 and 4.1.0 up to before 4.2.5 are affected. The vulnerable functionality exists only when entry filters are installed and the broker configuration allowOverrideEntryFilters is enabled. Versions 3.3.x and 4.0.x should be upgraded to at least 4.0.14; 4.1.x and 4.2.x users should upgrade to at least 4.2.5. Earlier releases are not vulnerable. The current supported release lines are 4.0.x and 5.0.x.

The CVSS score is 2.3, indicating low severity. EPSS information is not available and the vulnerability is not listed in CISA KEV. The attack vector requires an authenticated user with produce or consume permission on a non‑persistent topic (or its namespace) and a broker that has entry filters installed and allowOverrideEntryFilters enabled. In default deployments the override is disabled, so the change has no effect unless administratively enabled. An attacker can remove or replace the policy, causing subsequent subscriptions to receive no messages or undesired filters, effectively denying service to consumers. The impact is limited to message dispatch and does not expose payload or broker configuration beyond filter names.