CVE-2026-67414

Parser MQTT 5 w RabbitMQ akceptuje właściwość Request-Problem-Information na pakietach PUBLISH, mimo że jest ona ważna tylko dla CONNECT. Uwierzytelniony wydawca z uprawnieniem zapisu do tematu może spowodować, że broker zapisze i przekieruje tę nieprawidłową właściwość do subskrybenta, co prowadzi do wyjątku function_clause i zamknięcia połączenia MQTT lub Web MQTT ofiary. Problem naprawiono w wersjach 3.13.19, 4.0.24, 4.1.15, 4.2.10 i 4.3.5.

RabbitMQ to broker komunikatów i strumieniowania. Od wersji 4.0.0 do 4.0.24, 4.1.15, 4.2.10 i 4.3.4 zoptymalizowany parser server_mode AMQP 1.0 w deps/amqp10_common/src/amqp10_binary_parser.erl dopasowuje tekstowe prefiksy deskryptorów treści typu symbolic data, sequence i value bez weryfikacji ich zakodowanych długości symboli. Uwierzytelniony wydawca AMQP 1.0 z uprawnieniami zapisu może przesłać poprawnie sformułowany nieznany deskryptor rozpoczynający się od zarejestrowanego deskryptora treści, a RabbitMQ błędnie klasyfikuje i zapisuje bajty jako standardową sekcję treści. Ścisłe odbiorniki AMQP 1.0 mogą zakończyć działanie podczas dekodowania zapisanego wpisu. Dla treści błędnie sklasyfikowanych jako data, konwersja AMQP 0-9-1 lub inna konwersja międzyprotokołowa wykonuje pełne dekodowanie treści i może zakończyć proces protokołu odbiornika, przy czym dostarczanie wymagające potwierdzenia pozwala na powtarzające się awarie. Klasyfikacje sequence i value są normalnie transportowane jako nieprzezroczyste zakodowane ładunki na tej ścieżce konwersji. Broker pozostaje aktywny, a problem nie omija routingu ani autoryzacji. Problem naprawiono w wersjach 4.0.24, 4.1.15, 4.2.10 i 4.3.4.

W RabbitMQ w wersjach od 3.13.0 do 3.13.18, 4.0.23, 4.1.14, 4.2.9 i 4.3.3 występuje podatność Stored XSS w interfejsie zarządzania strumieniami. Nazwa DN z certyfikatu TLS peera jest renderowana bez escapowania, co pozwala na wstrzyknięcie złośliwego kodu HTML/JavaScript. Wymaga to konfiguracji z listenerem TLS i verifypeer oraz certyfikatu zaufanego przez listener, z atakującym kontrolowanym DN.

W RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 protokół strumieniowy przechowuje wartość FrameMax wynegocjowaną podczas uzgadniania Tune, ale nie porównuje jej z deklarowaną długością przychodzącej ramki przed buforowaniem. Zdalny klient może spowodować nadmierne zużycie pamięci i odmowę usługi, deklarując zbyt dużą ramkę.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 ma podatność polegającą na zastosowaniu list_to_atom/1 do każdego tokena rozdzielanego dwukropkiem w kontrolowanej przez atakującego wartości auth_mechanism, co trwale zużywa atomy maszyny wirtualnej Erlanga i może doprowadzić do awarii węzła przy dużym żądaniu. Eksploatacja wymaga użycia wtyczek Shovel lub Federation oraz posiadania tagu policymaker.

W RabbitMQ w wersjach od 4.2.0 do 4.2.8 i 4.3.2 udane żądanie POST /login powodowało, że is_authorized/2 ustawiało ciasteczko autoryzacyjne zawierające zakodowane w base64 dane uwierzytelniające username:password bez zabezpieczeń HttpOnly, Secure, SameSite ani wygaśnięcia. Ponieważ base64 to kodowanie, a nie szyfrowanie, atakujący z XSS, dostępem do sieci lub lokalnym dostępem do przeglądarki może odzyskać rzeczywiste dane logowania.

W wersjach RabbitMQ 3.4.x, 3.5.x oraz 3.6.x przed 3.6.9, a także w wersjach RabbitMQ dla PCF 1.5.x, 1.6.x przed 1.6.18 oraz 1.7.x przed 1.7.15, zidentyfikowano problem związany z przechowywaniem danych uwierzytelniających użytkowników w lokalnej pamięci przeglądarki bez daty wygaśnięcia. Umożliwia to ich odzyskanie w wyniku skoordynowanego ataku.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 — gdy brak jest pakietu CA, ssl_options/1 domyślnie używa [{verify, verify_none}] bez ostrzeżenia. Atakujący w pozycji man-in-the-middle może sfałszować odpowiedź JWKS, co prowadzi do akceptacji dowolnych tokenów JWT przez brokera.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 — plugin trust-store instaluje verify_fun, który nadpisuje błędy {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer}, gdy prezentowany certyfikat „pasuje” do białej listy. Klucz dopasowania opiera się wyłącznie na nazwie wystawcy i numerze seryjnym, które można łatwo podrobić, co pozwala na obejście uwierzytelniania klienta TLS.

W RabbitMQ Management, gdy włączony jest interfejs OAuth, powód błędu autoryzacji AMQP zawierający nazwę kolejki kontrolowaną przez atakującego jest renderowany jako HTML. Nazwa kolejki z elementem base może przekierować automatyczne odświeżanie, a przez CORS atakujący może przechwycić nagłówek Authorization administratora.