CVE-2026-67418

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.

W RabbitMQ w wersjach od 4.2.0 do 4.2.8 i 4.3.2 funkcja set_token_auth/2 wstawiała token bearer z nagłówka Authorization lub ciasteczka access_token do JavaScriptu bootstrap OAuth bez escapowania. Pozwalało to na wykonanie kodu JavaScript w kontekście interfejsu zarządzania. Luka jest eksponowana przed uwierzytelnieniem tylko gdy management.oauth_enabled jest true, a ścieżka przez ciasteczko wymaga dodatkowo umieszczenia ciasteczka access_token na hoście zarządzania.

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.

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

RabbitMQ w wersjach od 3.13.0 do 3.13.19, 4.0.24, 4.1.15, 4.2.10 i 4.3.5 zawiera podatność, w której odświeżenie poświadczeń OAuth utrzymuje wygasłe tagi runtime. Kiedy istniejące połączenie AMQP odświeża token OAuth z uprawnieniem impersonator na token z tą samą nazwą użytkownika, ale bez tego uprawnienia, tag 'impersonator' pozostaje w połączeniu. Dzięki temu połączenie (w tym nowo otwarte kanały) może dalej publikować wiadomości z obcym AMQP userid, mimo że powinno to być już odwołane.

Podatność w RabbitMQ przed wersją 4.3.5. Uwierzytelniony użytkownik, który może powiązać kolejkę z wymianą tematyczną i publikować do niej, może użyć kolejnych segmentów # w kluczu powiązania, co powoduje, że oba matchery tematyczne przetwarzają te same stany bez memoizacji. Skutkuje to duplikowaniem miejsc docelowych przed deduplikacją, co prowadzi do kombinatorycznego obciążenia CPU i pamięci, zakłócając routing dla wszystkich dzierżawców.

Parser parametrów Shovel w RabbitMQ konwertuje wartości parametrów kontrolowane przez atakującego na atomy Erlanga, które nie podlegają garbage collection, przed ich ograniczeniem lub sprawdzeniem dozwolonej listy. Atakujący może wyczerpać tablicę atomów węzła i spowodować odmowę usługi, a złośliwe parametry są trwale zapisywane i ponownie parsowane po restarcie.

Wtyczka rabbitmq_jms_topic_exchange w RabbitMQ przyjmuje kontrolowane przez klienta wyrażenie rjms_erlang_selector, którego ewaluator LIKE rozwija wildcardy do nakładających się fragmentów PCRE wykonywanych bez limitów dopasowania lub rekurencji. Uwierzytelniony najemca może wyczerpać CPU brokera i spowodować odmowę usługi.