Niski Odebrany

CVE-2026-105932

opublikowano: 21.10.2026, 21:16

modyfikacja: 21.10.2026, 21:16

Ocena CVSS

2.3

Niski · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Interfejs API REST administratora brokera Apache Pulsar udostępnia punkty końcowe umożliwiające odczytywanie, ustawianie i usuwanie zasad filtrowania wpisów na poziomie tematu. W przypadku tematów trwałych te punkty końcowe sprawdzają, czy obiekt wywołujący jest autoryzowany do operacji zasady tematu filtrów wpisów. Odpowiednie punkty końcowe dla tematów nietrwałych (/admin/v2/non-persistent/{tenant}/{namespace}/{topic}/entryFilters) nie wykonują tej kontroli autoryzacji. Jedyną kontrolą autoryzacji przeprowadzaną przez te punkty końcowe jest kontrola uprawnień wyszukiwania pośredniego, wykonywana podczas pobierania metadanych partycji tematu. jest obecny we wszystkich wersjach, których dotyczy problem.

W rezultacie, gdy włączone jest uwierzytelnianie i autoryzacja, uwierzytelniony użytkownik, któremu przyznano uprawnienia do tworzenia lub korzystania z nietrwałego tematu lub jego przestrzeni nazw, ale bez uprawnień do zarządzania zasadami tematu, może czytać, zastępować lub usuwać zasady filtrów wpisów na poziomie tematu dla tego tematu. Te operacje powinny być ograniczone do użytkowników z rolą administratora dzierżawy lub rolą superużytkownika. W tej analizie wpływu założono, że Pulsar został skonfigurowany z domyślnym dostawcą autoryzacji. W przypadku niestandardowych dostawców autoryzacji wpływ może być nieco inny.

Praktyczny wpływ jest ograniczony przez dwa wymagania dotyczące konfiguracji brokera, z których żadne nie jest domyślnie spełnione:

- Filtry wlotowe muszą zostać zainstalowane przez operatora. Implementacje filtrów wpisów są ładowane tylko podczas uruchamiania brokera z katalogu filtrów wpisów brokera, który domyślnie jest pusty. Żądanie może wybierać jedynie spośród filtrów wejściowych, które operator już wdrożył; ustawienie jakiejkolwiek innej nazwy filtra jest odrzucane. Ten problem nie pozwala wywołującemu zainstalować lub załadować kodu filtru wpisów ani uruchomić dowolnego kodu w brokerze.
— Zasady filtrów wpisów na poziomie tematu muszą mieć możliwość przesłaniania konfiguracji na poziomie brokera (allowOverrideEntryFilters, które jest domyślnie wyłączone). Gdy to ustawienie jest wyłączone, zasady filtrowania wpisów na poziomie tematu nie mają wpływu na wysyłanie wiadomości.

W przypadku wdrożeń, w których spełnione są oba warunki, nieautoryzowany użytkownik może usunąć zasadę filtrowania wpisów na poziomie tematu dla tematu nietrwałego, na przykład taką, która służy do ograniczania tego, które wiadomości są dostarczane konsumentom, lub zastosować inny zainstalowany filtr wpisów, który wstrzymuje wiadomości z subskrypcji tego tematu. Usunięcie go powoduje powrót tematu do filtrów wpisów na poziomie przestrzeni nazw lub poziomu brokera, które nie są usuwane. Zmieniona polityka dotyczy tylko dyspozytorów subskrypcji utworzonych po zmianie, na przykład dla nowych subskrypcji lub gdy subskrypcja zostanie utworzona ponownie po rozłączeniu wszystkich jej odbiorców; dyspozytorzy, którzy już istnieją, zachowują filtry wpisów, za pomocą których zostali utworzeni. Ponieważ tematy nietrwałe nie przechowują wiadomości, wiadomości wstrzymane przez filtr wpisów nie są dostarczane. Zapoznanie się z polityką ujawnia jedynie nazwy skonfigurowanych filtrów wpisów. Problem nie pozwala na odczytanie treści wiadomości, a filtry wpisów nie mogą modyfikować ładunków wiadomości. Nie ma to wpływu na tematy trwałe i zasady filtrów wpisów na poziomie przestrzeni nazw. Nie ma to wpływu na wersje Apache Pulsar starsze niż 3.3.0, ponieważ w tych wersjach sprawdzanie zasad tematu filtrów wpisów odbywa się w kodzie współdzielonym przez trwałe i nietrwałe punkty końcowe.

Ten problem dotyczy wersji Apache Pulsar od 3.3.0 przed 4.0.14 i od 4.1.0 przed 4.2.5.

- Użytkownicy wersji 3.3.xi 4.0.x powinni dokonać aktualizacji do wersji co najmniej 4.0.14.
- Użytkownicy wersji 4.1.xi 4.2.x powinni dokonać aktualizacji do co najmniej wersji 4.2.5.

Użytkownicy korzystający z wersji wcześniejszych niż wymienione powyżej powinni dokonać aktualizacji do wyżej wymienionych wersji z poprawkami lub do nowszych wersji.

Obecnie obsługiwane linie wydań Apache Pulsar to 4.0.x i 5.0.x. Harmonogram obsługiwanych wersji jest dostępny pod adresem https://pulsar.apache.org/contribute/release-policy/.

Użytkownicy, którzy nie mogą dokonać natychmiastowej aktualizacji i wdrożyli filtry wpisów, powinni pozostawić domyślną wartość parametruallowOverrideEntryFilters wynoszącą fałsz, tak aby zasady filtrów wpisów na poziomie tematu nie miały wpływu na wysyłanie wiadomości.

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 request can only select among entry filters the operator has already deployed; setting any other filter name is rejected. The issue does not allow a caller to install or load entry filter code or to run arbitrary code in the broker.
- Topic-level entry filter policies must be allowed to override the broker-level configuration (allowOverrideEntryFilters, which is disabled by default). When this setting is disabled, the topic-level entry filter policy has no effect on message dispatch.

In deployments where both conditions are met, an unauthorized user can remove the topic-level entry filter policy of a non-persistent topic, for example one used to restrict which messages are delivered to consumers, or apply a different installed entry filter that withholds messages from subscriptions of that topic. Removing it makes the topic fall back to the namespace-level or broker-level entry filters, which are not removed. A changed policy affects only subscription dispatchers created after the change, for example for new subscriptions or when a subscription is re-created after all of its consumers have disconnected; dispatchers that already exist keep the entry filters they were created with. Because non-persistent topics do not store messages, messages withheld by an entry filter are not delivered. Reading the policy discloses only the names of the configured entry filters. The issue does not allow reading message contents, and entry filters cannot modify message payloads. Persistent topics and namespace-level entry filter policies are not affected. Apache Pulsar versions before 3.3.0 are not affected, because in those versions the entry filters topic policy check is made in code shared by the persistent and non-persistent endpoints.

This issue affects Apache Pulsar versions from 3.3.0 before 4.0.14 and from 4.1.0 before 4.2.5.

- 3.3.x and 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 and have deployed entry filters should keep allowOverrideEntryFilters at its default value of false, so that topic-level entry filter policies do not affect message dispatch.

>_ Słabości (CWE)

CWE-862

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve