CVE-2026-105937
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 14 - wyżej niż 14% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Użytkownik może uzyskać dostęp do wiadomości z tematu w innym tenancie bez uprawnień do niego, a także spowodować trwałe usunięcie danych źródłowego tematu z BookKeeper i pamięci warstwowej, niezależnie od polityki retencji i subskrypcji. Ryzyko obejmuje wyciek danych oraz utratę niepotwierdzonych wiadomości.
Rekomendacja
Zaktualizuj Apache Pulsar do wersji co najmniej 4.0.14 (dla 4.0.x) lub 4.2.5 (dla 4.1.x i 4.2.x). Jeśli aktualizacja nie jest możliwa, ogranicz rolę administratora tenanta wyłącznie do zaufanych podmiotów.
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-105938Niskie
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.
- 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 shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic's managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW_SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW_TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths. As a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user's own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different. The user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic's ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic's schema, subject to the schema compatibility settings; existing schema versions are not replaced. In addition, the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source topic's ledgers. This can permanently delete the source topic's ledger data from BookKeeper and from tiered storage, regardless of the source topic's own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic's ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators. This issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation. - 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/. In the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW_SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic. Affected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS