CVE-2026-105938
NiskieCVSS 2.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 43 - wyżej niż 43% wszystkich znanych CVE
Streszczenie
Apache Pulsar nie stosował polityk subskrypcji (tryb Prefix lub uprawnienia do subskrypcji) w kilku administracyjnych operacjach REST API działających na subskrypcjach: czyszczeniu backlogu (dla nazwanej subskrypcji i wszystkich), unsubscribe oraz wygaszaniu wiadomości dla wszystkich subskrypcji tematu. Uwierzytelniony użytkownik z uprawnieniem consume na przestrzeni nazw lub temacie mógł ominąć te polityki i wyczyścić backlog, wygasić wiadomości lub usunąć subskrypcję, do której normalnie nie miałby dostępu.
Ocena ryzyka
Naruszenie integralności stanu subskrypcji: niepotwierdzone wiadomości mogą przestać być dostarczane, a pominięte wiadomości mogą zostać trwale usunięte. Operacje czyszczenia backlogu mogą też pominąć kursory replikacji geograficznej, przez co wiadomości nie zostaną zreplikowane do zdalnego klastra.
Rekomendacja
Zaktualizuj Apache Pulsar do wersji co najmniej 4.0.14 (linia 4.0.x) lub 4.2.5 (linie 4.1.x i 4.2.x), aktualizując wszystkie brokery w klastrze przed poleganiem na ograniczeniach na poziomie przestrzeni nazw. Jeśli aktualizacja nie jest możliwa natychmiast, ogranicz dostęp sieciowy do administracyjnego REST API brokera do zaufanych klientów administracyjnych.
Inne podatności w Apache Pulsar
Zobacz wszystkie- CVE-2026-105869Krytyczne
Podatność w Apache Pulsar dotyczy MultiRolesTokenAuthorizationProvider, który autoryzuje klienta na podstawie ról z niezweryfikowanego tokenu JWT. Gdy włączona jest anonimowa rola (anonymousUserRole) i uwierzytelnianie nie odrzuca żądań HTTP, klient może wysłać sfałszowany token z dowolnymi rolami i uzyskać autoryzację, w tym uprawnienia superużytkownika.
- CVE-2026-105945Wysokie
Usługa zarządzania pakietami Apache Pulsar z dostawcą storage FileSystemPackagesStorageProvider nie walidowała komponentu wersji nazwy pakietu, który mógł zawierać zakodowane w URL separatory ścieżek i odwołania do katalogu nadrzędnego. Pozwalało to na rozwiązanie ścieżki do lokalizacji pakietu w innym tenancie lub namespace, a kontrola zawierania w katalogu storage nie blokowała takiego dostępu. Uwierzytelniony użytkownik z uprawnieniem packages w dowolnym namespace mógł pobierać, nadpisywać lub usuwać pakiety innych tenantów/namespace'ów.
- CVE-2026-105942Wysokie
W Apache Pulsar wykryto dwie luki w mechanizmie autoryzacji żądań przekazywanych przez proxy w imieniu innego użytkownika. Pierwsza polega na autoryzowaniu oryginalnego użytkownika danymi uwierzytelniającymi proxy (dotyczy m.in. MultiRolesTokenAuthorizationProvider), druga pozwala pominąć sprawdzenie oryginalnego użytkownika przy operacjach administracyjnych tenanta, gdy rola proxy jest administratorem tenanta. Może to umożliwić użytkownikom wykonanie operacji wykraczających poza ich własne uprawnienia.
- CVE-2026-105937Wysokie
Podatność w Apache Pulsar dotyczy mechanizmu shadow topics (PIP-180). Broker autoryzuje użytkownika tylko względem tworzonego lub aktualizowanego tematu, a nie względem tematu źródłowego wskazanego we właściwości PULSAR.SHADOW_SOURCE. Umożliwia to uwierzytelnionemu użytkownikowi z uprawnieniami do tworzenia tematów lub edycji ich właściwości w jednym tenancie powiązanie tematu z tematem źródłowym w innym tenancie i odczyt jego zachowanych wiadomości.
- CVE-2026-105936Średnie
W Apache Pulsar endpoint functions connectors (/admin/v2/functions/connectors i /admin/v3/functions/connectors) zwraca katalog connectorów IO bez wymagania uprawnień super-użytkownika, podczas gdy endpoint worker connectors wymaga takich uprawnień. W rezultacie każdy uwierzytelniony klient może odczytać metadane katalogu connectorów niezależnie od posiadanej roli. Luka dotyczy wersji od 2.4.1 do 4.0.13 oraz od 4.1.0 do 4.2.4.
- CVE-2026-105935Średnie
Luka w Apache Pulsar dotyczy endpointu REST API Functions Worker służącego do wyzwalania funkcji. Worker publikuje wiadomość do tematu wejściowego funkcji, używając własnych poświadczeń brokera, a nie poświadczeń wywołującego, i nie sprawdza, czy wywołujący ma uprawnienia do produkowania do tego tematu. W wersjach przed 2.4.0 nie ma żadnej weryfikacji uprawnień wywołującego dla tego endpointu.
- CVE-2026-105934Wysokie
Apache Pulsar broker w wersjach 2.8.0–4.0.13 oraz 4.1.0–4.2.4 nie stosuje sprawdzenia roli administratora tenanta do wywołującego przy operacji truncate na temacie partycjonowanym. Zamiast tego broker wykonuje truncate każdej partycji własnym wewnętrznym klientem administracyjnym, więc uwierzytelniony użytkownik bez uprawnień administratora tenanta, ale z uprawnieniem lookup, może opróżnić dowolny temat partycjonowany. Powoduje to pominięcie niepotwierdzonego backlogu subskrypcji oraz trwałe usunięcie starszych ledgerów niezależnie od polityki retencji.
- CVE-2026-105933Niskie
Apache Pulsar pozwala administratorowi wymuszać szyfrowanie end-to-end wiadomości w namespace poprzez politykę encryption_required. Jeśli inicjalizacja tematu trwałego nie powiedzie się (np. błąd odczytu z magazynu metadanych lub błąd ładowania polityk tematu), broker loguje ostrzeżenie, wyłącza wymóg szyfrowania i kończy ładowanie tematu jako udane. W rezultacie uwierzytelniony klient z uprawnieniami do produkcji może publikować niezaszyfrowane wiadomości, które broker akceptuje i przechowuje, mimo że polityka namespace tego wymaga.
- CVE-2026-105932Niskie
W Apache Pulsar punkty końcowe REST API dla tematów niepersystentnych (/admin/v2/non-persistent/.../entryFilters) nie sprawdzają uprawnień do zarządzania polityką filtrów wpisów, w przeciwieństwie do tematów persystentnych. Uwierzytelniony użytkownik z uprawnieniami produce lub consume na temacie niepersystentnym może odczytać, zastąpić lub usunąć politykę filtrów wpisów tego tematu. Luka dotyczy wersji od 3.3.0 do 4.0.14 oraz od 4.1.0 do 4.2.5.
- CVE-2026-105931Niskie
Apache Pulsar broker udostępnia API REST do administracji transakcjami pod /admin/v3/transactions. Gdy włączone są uwierzytelnianie i autoryzacja, większość endpointów odczytu weryfikuje jedynie uwierzytelnienie i dostępność tematu lub koordynatora transakcji, nie sprawdzając uprawnień wywołującego do tenanta, przestrzeni nazw ani tematu. W efekcie każdy uwierzytelniony użytkownik, nawet bez żadnych uprawnień, może odczytać metadane i statystyki transakcji należących do innych tenantów.
Oryginalny opis (angielski, źródło NVD)
Apache Pulsar namespaces can restrict which roles may use a subscription, either with the Prefix subscription authentication mode, which requires a subscription name to start with the role name, or by granting permission on a subscription to specific roles. Topic-level subscription operations, such as consuming, skipping messages, resetting a cursor or deleting a subscription, apply these subscription policies. Several admin REST API operations that act on subscriptions did not apply them: - the namespace-level and bundle-level clear backlog operations, both for a named subscription and for all subscriptions; - the namespace-level and bundle-level unsubscribe operations; - the topic-level operation that expires messages for all subscriptions of a topic. With the default authorization provider, the namespace-level operations require only consume permission granted on the namespace, and the expire-all operation requires only consume permission on the topic. As a result, when authentication and authorization are enabled and a namespace uses the Prefix subscription authentication mode or subscription permissions, an authenticated user with such consume permission can clear the backlog of, expire messages of, or delete a subscription that the policies would deny to that user. Tenant admin or superuser access is not required. The clear backlog operations can also be applied to the cursors used for geo-replication, so that messages not yet replicated to a remote cluster are skipped. Deployments that do not configure the Prefix subscription authentication mode or subscription permissions (the defaults) are not affected by this bypass, because consume permission on the namespace or topic already allows these operations there. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different. The impact is on the integrity of subscription state. Clearing or expiring the backlog moves the subscription's cursor forward, so unacknowledged messages are no longer delivered to the subscription's consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespace's retention policy keeps them. The issue does not allow reading message contents, changing permissions or policies, or accessing other namespaces, and it does not affect the availability of the broker. In fixed versions, the namespace-level and bundle-level operations for a named subscription apply the subscription policies to that subscription, and the operations for all subscriptions, when requested by a user who is not a tenant admin or superuser, only act on the subscriptions that the user may access. Clearing the backlog of geo-replication cursors requires tenant admin or superuser access. Topic-level subscription operations apply the subscription policies for all types of authentication data, including that of the anonymous user role. 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. All brokers in a cluster must be upgraded before relying on the namespace-level restrictions, because brokers that have not been upgraded do not apply them when they receive the internal per-bundle requests. 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 to trusted administrative clients.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS