The Apache Pulsar broker admin REST API provides endpoints to read, set and remove the topic-level entry filter policy of a topic. For persistent topics these endpoints check that the caller is authorized for the entry filters topic policy operation. The corresponding endpoints for non-persistent topics (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) do not perform this authorization check. The only authorization check these endpoints perform is an indirect lookup permission check, made while the topic's partition metadata is retrieved; it is present in all affected versions.

As a result, when authentication and authorization are enabled, an authenticated user who has been granted produce or consume permission on a non-persistent topic, or on its namespace, but not permission to manage the topic's policies can read, replace or remove the topic-level entry filter policy of that topic. These operations should be restricted to users with the tenant admin role or the superuser role. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.

The practical impact is limited by two broker configuration requirements, neither of which is met by default:

- Entry filters must have been installed by the operator. Entry filter implementations are loaded only at broker startup from the broker's entry filters directory, which is empty by default. A…

The Apache Pulsar broker admin REST API provides endpoints to read, set and remove the topic-level entry filter policy of a topic. For persistent topics these endpoints check that the caller is authorized for the entry filters topic policy operation. The corresponding endpoints for non-persistent topics (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) do not perform this authorization check. The only authorization check these endpoints perform is an indirect lookup permission check, made while the topic's partition metadata is retrieved; it is present in all affected versions.

As a result, when authentication and authorization are enabled, an authenticated user who has been granted produce or consume permission on a non-persistent topic, or on its namespace, but not permission to manage the topic's policies can read, replace or remove the topic-level entry filter policy of that topic. These operations should be restricted to users with the tenant admin role or the superuser role. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different.

The practical impact is limited by two broker configuration requirements, neither of which is met by default:

- Entry filters must have been installed by the operator. Entry filter implementations are loaded only at broker startup from the broker's entry filters directory, which is empty by default. A…