CVE-2026-105926
ŚrednieCVSS 5.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 34 - wyżej niż 34% wszystkich znanych CVE
Streszczenie
Apache Pulsar broker nie sprawdzał autoryzacji dla komend GetSchema i GetOrCreateSchema w protokole binarnym — weryfikowano jedynie uwierzytelnienie klienta. Uwierzytelniony klient bez uprawnień do tematu mógł odczytać schemat z innego namespace/tenanta lub zarejestrować nową wersję schematu, co mogło powodować błędy niezgodności schematu u legalnych producentów i konsumentów. Problem dotyczy wdrożeń z włączoną autoryzacją w wersjach 2.2.0–4.0.13, 4.1.0–4.1.3 oraz 4.2.0–4.2.4.
Ocena ryzyka
Możliwe jest ujawnienie definicji schematów (nazwy i typy pól) z innych tenantów oraz zakłócenie działania tematu poprzez wymuszenie niezgodności schematu u legalnych klientów. Nie ma możliwości odczytu ani modyfikacji treści wiadomości.
Rekomendacja
Zaktualizuj Apache Pulsar do co najmniej 4.0.14 (dla 4.0.x) lub 4.2.5 (dla 4.1.x i 4.2.x). Po aktualizacji broker wymaga uprawnienia lookup dla GetSchema i produce dla GetOrCreateSchema.
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-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.
Oryginalny opis (angielski, źródło NVD)
The Pulsar broker serves two schema commands on its binary protocol: GetSchema, which returns the schema registered for a topic, and GetOrCreateSchema, which registers a new schema version for an existing topic. The broker handled both commands after checking only that the client connection was authenticated. Unlike the broker's other topic commands, such as those for creating producers and consumers or for looking up topics, these two commands did not check whether the authenticated client was authorized for the target topic. The Pulsar REST API endpoints for schemas were not affected. An authenticated client without any permission on the target topic, namespace or tenant could use these commands to: - read the schema registered for a topic in another namespace or tenant, disclosing the schema definition such as record field names and types. Message payloads are not disclosed. - register a new schema version on an existing topic in another namespace or tenant. The topic's schema compatibility and schema auto-update policies still apply. The issue does not allow message data to be read or modified, but a registered schema version can cause legitimate producers and consumers of that topic to fail with schema incompatibility errors until the schema is corrected by an administrator. The standard Pulsar client performs an authorized topic lookup before it sends these commands, so the missing check could not be observed when testing with the standard client. A client that implements the binary protocol directly is not required to perform that lookup first. This issue is relevant only to deployments that have authentication and authorization enabled. The GetSchema command is affected from Apache Pulsar 2.2.0, and the GetOrCreateSchema command from Apache Pulsar 2.5.0. After the fix, the broker requires the lookup permission on the topic for GetSchema and the produce permission on the topic for GetOrCreateSchema. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be slightly different. This issue affects Apache Pulsar versions from 2.2.0 before 4.0.14, from 4.1.0 through 4.1.3, and from 4.2.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. 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/.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS