Podatności RabbitMQ

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.

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

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.

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

W RabbitMQ handler otwarcia strumienia wywołuje tylko check_vhost_access, pomijając sprawdzenia limitów połączeń na węzeł/vhost/użytkownika, które rabbit_reader wykonuje dla AMQP. Uwierzytelniony najemca może całkowicie obejść skonfigurowane limity połączeń, łącząc się przez port 5552 zamiast 5672.

W RabbitMQ przed wersjami 4.2.7 i 4.3.1 funkcja rabbit_pid_codec:decompose_from_binary/1 przetwarza dostarczone przez klienta dane binarne zakodowane w ETF i wywołuje binary_to_atom(Node, utf8) na polu nazwy węzła. Jest to osiągalne z rabbit_volatile_queue:pid_from_name/2, które jest wywoływane dla każdej nazwy kolejki lub klucza routingu zaczynającego się od amq.rabbitmq.reply-to.. Sprawdzenie członkostwa w CandidateNodes następuje po utworzeniu atomu, a otaczający try/catch nie może odzyskać atomów (nigdy nie są usuwane przez GC). Każdy uwierzytelniony klient AMQP może zawiesić całą maszynę wirtualną Erlang (wszystkie vhosty, wszystkie połączenia) za pomocą około 1 miliona tanich żądań.

W RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11 i 4.2.6 funkcja parse_array_primitive/2 dla konstruktora 0x45 (list0) zwraca element o szerokości bajtowej B = 0. Otaczający parser array32 odczytuje 4-bajtowe Count z sieci i wykonuje pętlę Count razy, zużywając B bajtów za każdym razem; gdy B = 0, żadne dane wejściowe nie są konsumowane, a pętla buduje listę Count pustych elementów ograniczoną tylko 32-bitowym polem. Ramka SASL-mechanisms / SASL-init jest parsowana przez amqp10_framing:decode_bin/1 z rabbit_amqp_reader.erl:412 przed zakończeniem uwierzytelniania. Pre-auth incoming_max_frame_size (domyślnie 8192 bajty) ogranicza ramkę, a nie pole Count, więc 19-bajtowy ładunek z Count = 0xFFFFFFFF jest akceptowany. Nie ustawiono max_heap_size dla procesu czytnika. Nieuwierzytelniony atakujący sieciowy może zawiesić dowolny węzeł RabbitMQ z włączonym listenerem AMQP 1.0 (domyślny port 5672), wysyłając pojedynczą ~19-bajtową ramkę.