Podatności RabbitMQ

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.

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.

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.

Federation upstream w RabbitMQ pomija autoryzację vhost, umożliwiając dostęp do wiadomości między vhostami. Policy maker na jednym vhost może czytać i usuwać wiadomości z innego vhosta, do którego nie ma uprawnień, a przy domyślnym trybie ack wiadomości źródłowe są konsumowane, a nie kopiowane.

Natywny MQTT i MQTT over WebSocket za zaufanym frontendem PROXY Protocol w RabbitMQ mogą utracić adres klienta pochodzący z proxy przed sprawdzeniem loopback_users, przez co adres frontend-broker jest traktowany jako loopback. Atakujący z ważnymi poświadczeniami dla konta ograniczonego do loopback może obejść ograniczenie adresu źródłowego.

Niekompletna poprawka CVE-2026-44838 w RabbitMQ: funkcja escaperegexchar/1 nie escapuje znaku -, co umożliwia obejście uprawnień do tematów MQTT. Gdy szablon uprawnień umieszcza {clientid} wewnątrz klasy znaków [...], nisko uprzywilejowany użytkownik MQTT może rozszerzyć autoryzację tematów.

Shovel w RabbitMQ nie formatuje stanu logowanego przez crash reporter, co może pozostawić niezaszyfrowane poświadczenia w pliku zrzutu awarii. Gdy procesy worker Shovel ulegają awarii, OTP SASL zapisuje pełny stan procesu, w tym jawnotekstowe hasła i URI AMQP, do logu błędów.

W RabbitMQ OAuth2 guard isinteger(Exp) pomija sprawdzanie wygaśnięcia tokenu dla wykładniczej wartości exp typu float. Gdy IdP wysyła exp jako float, zarówno sprawdzenie przy logowaniu, jak i timer rozłączenia są pomijane, przez co wygasły token jest akceptowany, a połączenia nigdy nie wygasają.

W RabbitMQ AMQP 1.0 management exchange.declare pomija sprawdzenie uprawnień alternate-exchange. Użytkownik z uprawnieniem configure na wymianie X może kierować jej niekierowalne wiadomości do alternate exchange, do którego nie ma uprawnień zapisu.

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.

RabbitMQ w wersjach 4.2.0 do 4.2.8 i 4.3.2 zawiera podatność w funkcji get_auth_mechanism/1, która przy czyszczeniu ciasteczka używa term_to_binary/1 na atomie strict_auth_mechanism lub preferred_auth_mechanism. Powoduje to wygenerowanie nie-ASCII nazwy ciasteczka, co narusza RFC 6265 i może uniemożliwić przeglądarce usunięcie ustawień. Podatność nie ma bezpośredniego wpływu na wykonanie kodu, ale wpływa na trwałość preferencji po wylogowaniu.

Handler WebSocket Web STOMP w RabbitMQ nie wymusza max_frame_size ani login_timeout przed uwierzytelnieniem, co pozwala nieuwierzytelnionemu klientowi utrzymać połączenie wolnym strumieniem małych ramek i gromadzić nieograniczony stan przed uwierzytelnieniem. Wymagane jest włączenie wtyczki rabbitmq_web_stomp.

W RabbitMQ w wersjach od 4.0.0 do 4.0.22, 4.1.14, 4.2.7 i 4.3.1 występuje podatność polegająca na wyczerpaniu atomów. Funkcja toatom/1 jest wywoływana na segmencie ścieżki URL :name w endpointach global-parameters, co pozwala użytkownikowi z uprawnieniami policymaker na wielokrotne żądania i wyczerpanie tablicy atomów, prowadząc do awarii węzła.

W RabbitMQ w wersjach od 4.0.0 do 4.0.22, 4.1.14 i 4.2.7 występuje podatność polegająca na wyczerpaniu atomów dostępna tylko dla administratora. Funkcja settags/2 wywołuje toatom/1 na liście tagów użytkownika, a limit rozmiaru ciała żądania (20 MB) pozwala na przesłanie około 3-4 milionów krótkich tagów. Administrator może doprowadzić do awarii węzła pojedynczym żądaniem.

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

W RabbitMQ w liniach 3.13, 4.0, 4.1, 4.2 i 4.3 funkcja fill/2 podstawia ${username} do user_dn_pattern bez escapowania RFC 4514 DN, co pozwala na modyfikację powiązanego DN LDAP przez spreparowaną nazwę użytkownika. Wykorzystanie wymaga włączonego backendu rabbitmq_auth_backend_ldap z wzorcem zawierającym ${username}, odpowiedniego układu katalogu i ważnego hasła. Wersje poprawione są sprzeczne w różnych źródłach.

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.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 zawiera podatność polegającą na obejściu ochrony tagu 'protected' poprzez masowe usuwanie użytkowników. Administrator może usunąć konta usługowe oznaczone jako chronione, korzystając z punktu końcowego bulk-delete, co omija zabezpieczenie sprawdzające tag 'protected'.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 ma podatność na wyczerpanie tablicy atomów przez pole node w API zarządzania. Żądanie PUT /api/queues/:vhost/:name (oraz endpointy exchanges i bindings) przyjmuje pole JSON node, które jest konwertowane na atom bez sprawdzenia przynależności do klastra. Każda unikalna wartość trwale wycieka jeden atom, a około 900 tysięcy żądań może zawiesić maszynę wirtualną.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.22, 4.1.11, 4.2.6 i 4.3.1 ma podatność na wyczerpanie atomów przez wartości scope w tokenach OAuth2 JWT. Funkcja extractscopes/1 parsuje scope'y w formacie .tag: i konwertuje je na atomy. Podpis tokena jest weryfikowany, ale w konfiguracjach IdP, gdzie treść scope jest kontrolowana przez użytkownika, każde logowanie z nową wartością tagu wycieka jeden atom.

RabbitMQ w wersjach od 4.0.0 do 4.3.3, 4.2.9, 4.1.14 i 4.0.23 ma podatność w AMQP 1.0, gdzie endpoint GET /bindings w zarządzaniu ujawnia pełną topologię bindingów każdemu uwierzytelnionemu użytkownikowi AMQP bez sprawdzania uprawnień do zasobów. W przeciwieństwie do innych operacji w tym samym module, GET /bindings nie sprawdza uprawnień i zwraca listę bindingów bez zmian.

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.

RabbitMQ w wersjach przed 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.1 pozwala użytkownikowi z tagiem monitorowania usuwać lub restartować dowolne dynamiczne shovel w każdym vhost, który widzi. Endpoint zarządzania shovel deleguje autoryzację do sprawdzenia monitorującego, mimo że operacja DELETE powinna być ograniczona do roli policymaker. Problem naprawiono w wymienionych wersjach.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 nie weryfikuje nagłówka Origin podczas uaktualnienia WebSocket w handlerach Web-MQTT i Web-STOMP. Przy włączonym ssl_cert_login=true przeglądarka automatycznie przedstawia certyfikat klienta, więc złośliwy JavaScript w przeglądarce ofiary może uwierzytelnić się jako ofiara.

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 4.2.7 i 4.3.1 nie nakłada jawnego limitu dopasowań podczas kompilacji wzorców LIKE do wyrażeń regularnych, co pozwala uwierzytelnionemu konsumentowi AMQP 1.0 z uprawnieniami odczytu i zapisu na kolejce strumieniowej wywołać znaczne zużycie CPU poprzez spreparowany filtr LIKE. Każda dostarczona wiadomość może powodować około 100-200 ms obciążenia CPU, co przy tysiącach wiadomości i równoległych sesjach daje amplifikację. Problem został naprawiony w wersjach 4.2.7 i 4.3.1.

RabbitMQ przed wersjami 4.3.0, 4.2.6, 4.1.11, 4.0.20 i 3.13.15 przechowuje wartość BodySize z nagłówka content-header bez walidacji względem max_message_size. Klient może zadeklarować body_size = 2^63-1 i strumieniować fragmenty, przez co kontrola rozmiaru nigdy się nie uruchamia, a proces czytający gromadzi nieograniczoną ilość pamięci. Prowadzi to do wyczerpania pamięci węzła lub alarmu pamięciowego i degradacji wszystkich wydawców w klastrze.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 włącza kompresję permessage-deflate w WebSocket (RFC 7692) bez limitu rozmiaru ramki i bez limitu rozmiaru wyjściowego dekompresji. Nieuwierzytelniony atakujący może wysłać silnie skompresowaną ramkę WebSocket (tzw. bombę zlib), która po dekompresji zajmuje gigabajty pamięci, powodując awarię węzła RabbitMQ z włączoną wtyczką Web-MQTT.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 wywołuje rabbit_data_coercion:atomize_keys/1 (niebezpieczny wariant używający binary_to_atom) na mapie metadanych vhosta. Administrator importujący spreparowany plik definicji może wyczerpać tablicę atomów i zawiesić węzeł w jednym żądaniu.

RabbitMQ przed wersjami 4.2.7 i 4.3.1 w ścieżce wyszukiwania parametrów runtime konwertuje segment :component z URL na atom za pomocą rabbit_data_coercion:to_atom/1, tworząc nowy atom dla każdej nieznanej wartości. Uprawniony policymaker może wysłać około miliona żądań z różnymi wartościami component, wyczerpując tablicę atomów i zawieszając węzeł.

W RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.1 konsument trace tworzy ścieżkę wyjściową bez sprawdzenia bezpieczeństwa ścieżki względnej, mimo że strona odczytu takie sprawdzenie wykonuje. Administrator może poprzez parametr name zapisać plik z rozszerzeniem .log w dowolnej lokalizacji zapisywalnej przez użytkownika rabbitmq, np. /etc/cron.d/x.log.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0: shovel AMQP 0-9-1 usuwa poświadczenia przed zapisaniem URI połączenia, ale shovel AMQP 1.0 przechowuje surowy URI zawierający hasło. Zapisany URI jest widoczny przez GET /api/shovels oraz rabbitmqctl shovel_status.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0: przy tworzeniu bindingu na wymianie x-jms-topic funkcja add_binding/3 odczytuje argument rjms_erlang_selector i przetwarza go przez erl_scan:string/1 oraz erl_parse:parse_term/1. erl_scan:string/1 internuje każdy atom, a validate_binding/2 jest no-op bez limitu długości. Uwierzytelniony użytkownik AMQP o niskich uprawnieniach może zawiesić cały węzeł brokera w mniej niż 100 wywołaniach bind.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0: add_binding/3 parsuje klucz routingu jako całkowitą wagę N i oblicza pozycje pierścienia przez lists:seq(NextN0, NextN0 + N - 1). validate_binding/2 sprawdza tylko N >= 1, bez górnego limitu. Użytkownik z uprawnieniami zapisu na wymianie consistent-hash może utworzyć binding z ogromną wagą, alokując setki megabajtów na każdym węźle klastra.

W RabbitMQ przed wersjami 4.0.22, 4.1.11, 4.2.6 i 4.3.0 handler HTTP accept_content/2 wywołuje create_super_stream bez wymaganego sprawdzenia uprawnień configure na wymianie i kolejkach partycji, które jest obecne w ścieżce protokołu strumieniowego. Użytkownik z tagiem management i dostępem do vhosta, ale bez uprawnień configure, może tworzyć super-strumienie przez API HTTP.

RabbitMQ przed wersjami 4.1.11, 4.2.6 i 4.3.0: validate_partitions sprawdza tylko, że żądana liczba partycji wynosi co najmniej 1, bez górnego limitu. Duża wartość, np. lists:seq(0, 500000000), alokuje około 8 GB pamięci.

W interfejsie zarządzania RabbitMQ (wersje przed 3.13.15, 4.0.20, 4.1.11 i 4.2.6) dane z certyfikatu klienta TLS, takie jak Subject i Issuer DN, są wyświetlane bez escapowania HTML. Podatność występuje, gdy listener TLS ma włączoną opcję verify_peer, a atakujący posiada certyfikat klienta podpisany przez zaufany urząd CA z dowolnym Subject CN. Administrator przeglądający szczegóły takiego połączenia w panelu może stać się ofiarą ataku XSS, co prowadzi do przejęcia jego sesji.

W RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.1 trasa /federation-links/.../restart używa is_authorized_monitor akceptującego tag monitoring, a DELETE wywołuje restart łącza federacji bez sprawdzenia podniesionych uprawnień. Użytkownik z tagiem monitoring może zrestartować dowolne łącze federacji.

W RabbitMQ funkcja match_value/3 przekazuje dostarczone przez użytkownika wyrażenie regularne ?name= do re:run bez opcji match_limit i wykonuje je raz na każdy zasób w wyniku. Przy dużym zbiorze zasobów pojedyncze żądanie może zużyć wiele minut CPU, a równoległe żądania wysycają schedulery. Ścieżka jest osiągalna przez normalne użycie API z opcją use_regex=true.

W RabbitMQ funkcja get_chunk_selector/1 wywołuje binary_to_atom na surowej właściwości <<"chunk_selector">> dostarczonej przez klienta w ramkach subscribe i resolve_offset_spec, bez białej listy i bez istniejącej walidacji. Uwierzytelniony klient strumienia z prawem odczytu dowolnego strumienia może zawiesić węzeł brokera.

W RabbitMQ przed wersjami 4.1.13, 4.2.7 i 4.3.0 is_authorized/2 używa is_authorized_monitor dla wszystkich metod, a DELETE resetuje liczniki prób uwierzytelnienia. Użytkownik z tagiem monitoring może wyzerować te liczniki przez DELETE /api/auth/attempts/:node, usuwając dowody aktywności brute-force.

W RabbitMQ makro ?LOG_DEBUG formatuje całą mapę stanu Shovel, w tym pole 'uris' zawierające odszyfrowane URI z poświadczeniami. Przy włączonym logowaniu DEBUG zakończenie autodelete shovela zapisuje pełną mapę stanu, w tym amqp://user:password@host/, do pliku logu brokera.