Niski Odebrany

CVE-2026-105933

opublikowano: 21.10.2026, 21:16

modyfikacja: 21.10.2026, 21:16

Ocena CVSS

2.3

Niski · v4.0

Oficjalne źródła

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

Apache Pulsar umożliwia administratorowi wymaganie kompleksowego szyfrowania wiadomości dla wszystkich tematów w przestrzeni nazw poprzez ustawienie zasady przestrzeni nazw szyfrowanie_required. Gdy ta zasada jest ustawiona, broker odrzuca wiadomości publikowane bez szyfrowania.

Kiedy broker ładuje temat trwały, w ramach inicjowania tematu odczytuje zasady przestrzeni nazw i zasady poziomu tematu. Jeśli etap tej inicjalizacji nie powiedzie się, na przykład z powodu błędu odczytu z magazynu metadanych, niepowodzenia ładowania zasad na poziomie tematu lub niepowodzenia w późniejszym etapie inicjalizacji, broker rejestruje ostrzeżenie, wyłącza wymaganie szyfrowania dla tego tematu i kończy ładowanie tematu tak, jakby się powiodło. Temat jest następnie udostępniany z nie wymuszanym szyfrowaniem_required, mimo że wymagają tego zasady dotyczące przestrzeni nazw. Zasady na poziomie tematu, których nie udało się wczytać, również nie zostaną zastosowane.

Chociaż wymóg szyfrowania nie jest egzekwowany, uwierzytelniony klient z uprawnieniami do tworzenia odpowiedniego tematu może publikować wiadomości, które nie są zaszyfrowane, a broker je akceptuje i przechowuje. Dotyczy to zarówno producentów utworzonych po załadowaniu tematu, jak i producentów, którzy byli już połączeni. Wiadomości publikowane z szyfrowaniem pozostają zaszyfrowane; problem nie ujawnia treści zaszyfrowanych wiadomości ani kluczy szyfrujących.

Stan ten nie ogranicza się do awarii przejściowych. Jeśli przyczyna niepowodzenia inicjalizacji będzie się powtarzać, wymaganie szyfrowania zostanie ponownie wyłączone przy każdym załadowaniu tematu, na przykład po zwolnieniu tematu, ponownym przypisaniu pakietu przestrzeni nazw lub ponownym uruchomieniu brokera. Aktualizacja zasad przestrzeni nazw przywraca egzekwowanie w załadowanym temacie, ale tylko do czasu ponownego załadowania tematu. Egzekucja zostanie przywrócona niezawodnie dopiero po usunięciu podstawowej przyczyny niepowodzenia i ponownym załadowaniu tematu. Broker rejestruje ostrzeżenie, gdy wymóg szyfrowania jest wyłączony, ale ładowanie tematu jest zgłaszane jako pomyślne, a stan wymagania szyfrowania nie jest pokazywany w statystykach tematów.

W wersjach poprawionych błąd podczas inicjalizacji tematu powoduje niepowodzenie ładowania tematu i można go ponowić, zamiast ładować temat z wyłączonym wymogiem szyfrowania.

Ten problem dotyczy wersji Apache Pulsar od 1.22.0 – inkubacja 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 korzystają z szyfrowania_required i nie mogą natychmiast dokonać aktualizacji, mogą monitorować dzienniki brokera pod kątem ostrzeżeń zawierających „isEncryptionRequired zostanie ustawione na wartość false” (dokładna treść komunikatu różni się w zależności od wersji), rozwiązać podstawową przyczynę niepowodzenia, a następnie ponownie załadować temat, którego dotyczy problem i potwierdzić, że ostrzeżenie się nie powtórzy.

Apache Pulsar allows an administrator to require end-to-end message encryption for all topics in a namespace by setting the encryption_required namespace policy. When this policy is set, the broker rejects messages that are published without encryption.

When the broker loads a persistent topic, it reads the namespace policies and the topic-level policies as part of topic initialization. If a step of this initialization fails, for example because of an error reading from the metadata store, a failure loading the topic-level policies or a failure in a later initialization step, the broker logs a warning, disables the encryption requirement for that topic, and completes the topic load as if it had succeeded. The topic is then served with encryption_required not enforced, even though the namespace policy requires it. Topic-level policies that could not be loaded are also not applied.

While the encryption requirement is not enforced, an authenticated client with permission to produce to the affected topic can publish messages that are not encrypted, and the broker accepts and stores them. This applies both to producers created after the topic was loaded and to producers that were already connected. Messages published with encryption remain encrypted; the issue does not expose the content of encrypted messages or the encryption keys.

The condition is not limited to transient failures. If the cause of the initialization failure persists, the encryption requirement is disabled again each time the topic is loaded, for example after a topic unload, a namespace bundle reassignment or a broker restart. An update to the namespace policies restores enforcement on a loaded topic, but only until the topic is loaded again. Enforcement is reliably restored only once the underlying cause of the failure has been resolved and the topic has been loaded again. The broker logs a warning when the encryption requirement is disabled, but the topic load is reported as successful and the state of the encryption requirement is not shown in the topic statistics.

In fixed versions, a failure during topic initialization causes the topic load to fail so that it can be retried, instead of loading the topic with the encryption requirement disabled.

This issue affects Apache Pulsar versions from 1.22.0-incubating 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 rely on encryption_required and cannot upgrade immediately can monitor the broker logs for warnings containing "isEncryptionRequired will be set to false" (the exact wording of the message differs between releases), resolve the underlying cause of the failure, and then reload the affected topic and confirm that the warning does not recur.

>_ Słabości (CWE)

CWE-636

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