Wysoki Odebrany

CVE-2026-105942

opublikowano: 21.10.2026, 21:16

modyfikacja: 21.10.2026, 21:16

Ocena CVSS

7.7

Wysoki · v4.0

Oficjalne źródła

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

Kiedy skonfigurowana rola proxy wysyła żądanie do brokera w imieniu innego użytkownika (pierwotnego głównego podmiotu), broker jest zaprojektowany tak, aby autoryzować zarówno rolę proxy, jak i pierwotnego głównego podmiotu oraz zezwalać na żądanie tylko wtedy, gdy obaj są autoryzowani, tak aby pierwotny podmiot zabezpieczeń nie mógł przekroczyć swoich własnych uprawnień. Dwie wady osłabiły tę kontrolę.

Po pierwsze, pierwotny podmiot główny został autoryzowany przy użyciu danych uwierzytelniających serwera proxy, a nie własnych. W administracyjnym interfejsie API REST brokera i procesie roboczym funkcji dotyczy to każdego żądania proxy. W przypadku protokołu binarnego Pulsar miało to zastosowanie, gdy serwer proxy nie przesłał poświadczeń klienta do brokera, co było domyślnym ustawieniem serwera proxy Pulsar w wersjach, których dotyczy problem. Dostawcy autoryzacji, którzy rozpoznają uprawnienia tylko z nazwy roli, na przykład domyślny dostawca autoryzacji, nie są dotknięci tą wadą. Dostawca autoryzacji tokenu wielozadaniowego (MultiRolesTokenAuthorizationProvider), dodany w Apache Pulsar 2.8.1, rozpoznaje role na podstawie roszczeń roli tokena w podanych danych uwierzytelniających. Kiedy serwer proxy uwierzytelnia się u brokera za pomocą własnego tokena, pierwotny podmiot zabezpieczeń został zatem autoryzowany wszystkimi rolami w tokenie serwera proxy. Jeśli którakolwiek z tych ról jest rolą superużytkownika lub administratora dzierżawy, każdy użytkownik, którego żądania są przekazywane przez ten serwer proxy, może wykonywać operacje wymagające tych uprawnień bez ich wstrzymywania. Podobny wpływ może mieć wpływ na niestandardowych dostawców autoryzacji korzystających z danych uwierzytelniających.

Po drugie, niezależnie od dostawcy autoryzacji, sprawdzenie przez administratora dzierżawy żądania interfejsu API REST administratora proxy zakończyło się pomyślnie bez sprawdzania pierwotnego podmiotu zabezpieczeń, gdy rola serwera proxy sama była rolą administratora dzierżawy. We wdrożeniach, w których rolą serwera proxy jest administrator dzierżawy, w tym z domyślnym dostawcą autoryzacji, każdy użytkownik, którego żądania są przekazywane przez ten serwer proxy, może wykonywać operacje administracyjne dzierżawy na tej dzierżawie. To zachowanie występuje od wersji 2.8.4 w wydaniach 2.8.x, od 2.9.3 w wydaniach 2.9.x i od 2.10.1.

Pierwsza wada nie dotyczy wdrożeń, które nie korzystają z dostawcy autoryzacji tokenu wielozadaniowego ani dostawcy niestandardowego korzystającego z danych uwierzytelniających, a w przypadku dostawcy autoryzacji tokenu wielozadaniowego nie są to również wdrożenia, których serwery proxy nie uwierzytelniają brokera za pomocą tokenu. Druga usterka nie dotyczy wdrożeń, w których żadna rola serwera proxy nie jest wymieniona jako rola administratora dzierżawy. Rola serwera proxy, która jest superużytkownikiem, ale nie jest wymieniona jako administrator dzierżawy, nie wyzwala jej, ponieważ kontrola administratora dzierżawy wbudowanych dostawców autoryzacji uwzględnia tylko role administratora dzierżawy. może się to różnić w przypadku niestandardowych dostawców autoryzacji, którzy traktują administratorów dzierżawy jako administratorów.

W ustalonych wersjach zarówno rola proxy, jak i pierwotny podmiot zabezpieczeń są autoryzowane dla każdego żądania przesyłanego za pośrednictwem serwera proxy, a pierwotny podmiot zabezpieczeń jest autoryzowany wyłącznie przy użyciu własnych danych uwierzytelniających. W przypadku dostawcy autoryzacji tokenu wielozadaniowego role przekazanego tokenu są używane dla pierwotnego podmiotu zabezpieczeń tylko wtedy, gdy ten token uwierzytelnia się jako pierwotny podmiot zabezpieczeń; w przeciwnym razie używana będzie tylko nazwa roli pierwotnego podmiotu zabezpieczeń. W przypadku kontroli administratora dzierżawy rola serwera proxy i pierwotny podmiot zabezpieczeń muszą być superużytkownikami lub administratorami dzierżawy dzierżawy.

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/.

When a configured proxy role sends a request to the broker on behalf of another user (the original principal), the broker is designed to authorize both the proxy role and the original principal and to allow the request only if both are authorized, so that the original principal cannot exceed its own permissions. Two flaws weakened this check.

First, the original principal was authorized with the proxy's authentication data instead of its own. On the admin REST API of the broker and the functions worker, this applied to every proxied request. On the Pulsar binary protocol, it applied when the proxy did not forward the client's credentials to the broker, which was the default of the Pulsar proxy in the affected versions. Authorization providers that resolve permissions from the role name only, such as the default authorization provider, are not affected by this flaw. The multi-role token authorization provider (MultiRolesTokenAuthorizationProvider), added in Apache Pulsar 2.8.1, resolves roles from the role claim of the token in the authentication data it is given. When a proxy authenticates to the broker with its own token, the original principal was therefore authorized with all roles in the proxy's token. If any of those roles is a superuser or tenant admin role, any user whose requests are forwarded by that proxy can perform operations that need those permissions without holding them. Custom authorization providers that use the authentication data could be affected in a similar way.

Second, independently of the authorization provider, the tenant admin check of a proxied admin REST API request succeeded without checking the original principal when the proxy role was itself an admin role of the tenant. In deployments where a proxy role is a tenant admin, including with the default authorization provider, any user whose requests are forwarded by that proxy could perform tenant administration operations on that tenant. This behavior is present from 2.8.4 in the 2.8.x releases, from 2.9.3 in the 2.9.x releases, and from 2.10.1 onwards.

Deployments that use neither the multi-role token authorization provider nor a custom provider that uses the authentication data are not affected by the first flaw, and with the multi-role token authorization provider, neither are deployments whose proxies do not authenticate to the broker with a token. Deployments in which no proxy role is listed as an admin role of a tenant are not affected by the second flaw. A proxy role that is a superuser but is not listed as a tenant admin does not trigger it, because the tenant admin check of the built-in authorization providers only considers the tenant's admin roles; this can differ for custom authorization providers that treat superusers as tenant admins.

In fixed versions, both the proxy role and the original principal are authorized for each proxied request, and the original principal is authorized only with its own authentication data. With the multi-role token authorization provider, the roles of a forwarded token are used for the original principal only when that token authenticates as the original principal; otherwise only the original principal's role name is used. For tenant admin checks, the proxy role and the original principal must each be a superuser or a tenant admin of the tenant.

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/.

>_ Słabości (CWE)

CWE-863

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