CVE-2026-67418

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.

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 plik deps/amqp10_common/src/amqp10_binary_parser.erl materializuje każdy element tablic AMQP 1.0, których wspólny konstruktor ma zerową szerokość, ograniczając jedynie liczbę elementów w każdej tablicy, a nie łączne tablice w ramce. Po zakończeniu uwierzytelniania SASL nisko uprzywilejowany klient może wysłać zwykłą ramkę zawierającą wiele indywidualnie dozwolonych tablic, powodując rozszerzenie małej ramki do bardzo dużej sterty procesu czytnika przed późniejszą walidacją ramki lub autoryzacją. Ponieważ deps/rabbit/src/rabbit_amqp_reader.erl usuwa zabezpieczenie max_heap_size przed uwierzytelnianiem po zalogowaniu, powtarzane lub równoczesne ramki mogą wywołać alarm pamięci na poziomie węzła, zablokować wydawców lub wyczerpać pamięć brokera. 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.