Krytyczny Odebrany

CVE-2026-105869

opublikowano: 21.10.2026, 20:17

modyfikacja: 21.10.2026, 20:17

Ocena CVSS

9.2

Krytyczny · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/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.

MultiRolesTokenAuthorizationProvider Apache Pulsar autoryzuje klienta ze wszystkimi rolami wymienionymi w oświadczeniu jego tokenu internetowego JSON (JWT). Dostawca jest przeznaczony do użytku z uwierzytelnianiem tokenem, które weryfikuje token przed autoryzacją. Dostawca nie zweryfikował samego tokena: przeanalizował oświadczenia tokena po usunięciu podpisu i zaufał, że uwierzytelnienie już to sprawdziło.

Jeśli uwierzytelnianie i autoryzacja są włączone z niepustym ustawieniem anonimowej roli użytkownika, niektóre żądania HTTP, których uwierzytelnienie nie powiodło się, nie są odrzucane, ale są obsługiwane jako żądania roli użytkownika anonimowego. W przypadku punktów końcowych HTTP brokera, takich jak interfejs API REST administratora, to rozwiązanie awaryjne dotyczy żądań, które nie podają metody uwierzytelniania i wymagają, aby parametr strictAuthMethod miał wartość false (wartość domyślna), jeśli to ustawienie jest dostępne. W przypadku interfejsu API protokołu WebSocket nieprawidłowe poświadczenia mogą również wynikać z roli użytkownika anonimowego; ta ścieżka nie wymusza metody strictAuthMethod. Dane uwierzytelniające przechowywane dla takiego żądania nadal zawierały nagłówek Authorization żądania. Następnie MultiRolesTokenAuthorizationProvider odczytał token okaziciela z tego nagłówka bez weryfikowania jego podpisu i autoryzował żądanie przy użyciu ról w żądaniu roli tokenu.

W rezultacie we wdrożeniach korzystających z MultiRolesTokenAuthorizationProvider razem z niepustą anonimową rolą anonimowego użytkownika i które pozwalają na tę rezerwę, nieuwierzytelniony klient może wysłać żądanie HTTP, na przykład do interfejsu API REST administratora lub interfejsu API WebSocket, z sfałszowanym lub niepodpisanym tokenem, który zawiera listę dowolnych ról i uzyskać autoryzację przy użyciu tych ról. Wpływ może obejmować dostęp superużytkownika, gdy token zawiera listę roli skonfigurowanej w superUserRoles, umożliwiając klientowi odczytywanie i zmienianie dzierżawców, przestrzeni nazw, tematów, uprawnień i konfiguracji brokera. Nie są wymagane żadne ważne dane uwierzytelniające.

Nie ma to wpływu na wdrożenia, jeśli korzystają z domyślnego dostawcy autoryzacji (PulsarAuthorizationProvider) lub innego dostawcy autoryzacji, albo jeśli nie ustawiono opcji anonimowyUserRole (wartość domyślna). Nie ma to wpływu na żądania, które pomyślnie uwierzytelniły się przy użyciu prawidłowego tokenu, ponieważ token odczytywany przez MultiRolesTokenAuthorizationProvider jest tokenem zweryfikowanym przez uwierzytelnianie. Ten problem nie dotyczy połączeń korzystających z protokołu binarnego Pulsar, ponieważ broker nie przechowuje danych uwierzytelniających klienta dla połączeń przypisanych do roli użytkownika anonimowego.

W ustalonych wersjach MultiRolesTokenAuthorizationProvider uzyskuje role tylko z tokenów, które zweryfikował skonfigurowany dostawca uwierzytelniania tokenu przy użyciu skonfigurowanych kluczy i ustawień walidacji. Żądania HTTP brokera przypisane do roli użytkownika anonimowego są autoryzowane tylko jako ta rola, a nieprawidłowe tokeny nie mogą zapewniać dodatkowych ról żądaniom protokołu WebSocket. Nie można uruchomić brokera, jeśli skonfigurowano MultiRolesTokenAuthorizationProvider z włączoną autoryzacją, ale bez dostawcy uwierzytelniania tokenu.

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

- Użytkownicy wersji 4.0.x powinni dokonać aktualizacji do co najmniej wersji 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, mogą usunąć ustawienie anonimowej roli użytkownika z konfiguracji brokera i usługi WebSocket lub ograniczyć dostęp sieciowy do punktów końcowych HTTP tych usług do zaufanych klientów.

Apache Pulsar's MultiRolesTokenAuthorizationProvider authorizes a client with all roles listed in a claim of its JSON Web Token (JWT). The provider is intended for use with token authentication, which verifies the token before authorization. The provider did not verify the token itself: it parsed the token's claims with the signature removed and trusted that authentication had already checked it.

When authentication and authorization are enabled with a non-empty anonymousUserRole setting, some HTTP requests whose credentials fail authentication are not rejected, but are handled as requests of the anonymous user role. For the broker's HTTP endpoints, such as the admin REST API, this fallback applies to requests that do not name an authentication method and requires strictAuthMethod to be false (the default) where that setting is available. For the WebSocket API, failed credentials can also fall back to the anonymous user role; this path does not enforce strictAuthMethod. The authentication data kept for such a request still contained the request's Authorization header. MultiRolesTokenAuthorizationProvider then read the bearer token from that header without verifying its signature and authorized the request with the roles in the token's role claim.

As a result, in deployments that use MultiRolesTokenAuthorizationProvider together with a non-empty anonymousUserRole and that permit this fallback, an unauthenticated client can send an HTTP request, for example to the admin REST API or the WebSocket API, with a forged or unsigned token that lists arbitrary roles, and be authorized with those roles. The impact can include super-user access when the token lists a role configured in superUserRoles, allowing the client to read and change tenants, namespaces, topics, permissions and broker configuration. No valid credentials are required.

Deployments are not affected if they use the default authorization provider (PulsarAuthorizationProvider) or another authorization provider, or if anonymousUserRole is not set (the default). Requests that authenticate successfully with a valid token are not affected, because the token that MultiRolesTokenAuthorizationProvider reads is the token that authentication verified. Connections that use the Pulsar binary protocol are not affected by this issue, because the broker does not keep client authentication data for connections that it assigns to the anonymous user role.

In fixed versions, MultiRolesTokenAuthorizationProvider obtains roles only from tokens that the configured token authentication provider has verified, using its configured keys and validation settings. Broker HTTP requests that are assigned to the anonymous user role are authorized only as that role, and invalid tokens cannot supply additional roles to WebSocket requests. The broker fails to start if MultiRolesTokenAuthorizationProvider is configured with authorization enabled but without a token authentication provider.

This issue affects Apache Pulsar versions from 2.8.1 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.

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 remove the anonymousUserRole setting from the broker and WebSocket service configurations, or restrict network access to the HTTP endpoints of these services to trusted clients.

>_ Słabości (CWE)

CWE-347

>_ 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