Luki w RabbitMQ mogą ujawnić sekrety OAuth i metadane kolejek między tenantami - Security Bez Tabu

Luki w RabbitMQ mogą ujawnić sekrety OAuth i metadane kolejek między tenantami

Cybersecurity news

Wprowadzenie do problemu / definicja

W RabbitMQ ujawniono dwie podatności związane z kontrolą dostępu, które wpływają na bezpieczeństwo środowisk korzystających z uwierzytelniania OAuth 2 oraz architektur wielodzierżawczych. Problem dotyczy zarówno poufności danych uwierzytelniających, jak i izolacji logicznej pomiędzy tenantami korzystającymi ze wspólnego brokera wiadomości.

W praktyce jedna z luk może prowadzić do przejęcia pełnej kontroli nad brokerem, a druga umożliwia nieuprawniony wgląd w metadane kolejek i exchange’y. To istotne zagrożenie dla organizacji, które wykorzystują RabbitMQ jako kluczowy element komunikacji między usługami, aplikacjami i procesami integracyjnymi.

W skrócie

Badacze bezpieczeństwa opisali dwa błędy obecne w RabbitMQ od linii wydań 3.13.0 wzwyż. Pierwsza podatność, CVE-2026-57219, pozwala nieautoryzowanemu atakującemu ujawnić sekret klienta OAuth przez przestarzały endpoint HTTP API. Druga, CVE-2026-57221, wynika z braku właściwej autoryzacji i umożliwia zalogowanemu użytkownikowi odczyt nazw kolejek i exchange’y oraz ich podstawowych statystyk w ramach tego samego virtual hosta.

Producent udostępnił poprawki w wersjach 4.3.0, 4.2.6, 4.1.11, 4.0.20 oraz 3.13.15. Dla administratorów oznacza to konieczność pilnej weryfikacji wersji, konfiguracji management API oraz modelu uprawnień.

Kontekst / historia

RabbitMQ pozostaje jednym z najczęściej wykorzystywanych brokerów wiadomości w systemach rozproszonych, środowiskach mikroserwisowych i platformach integracyjnych. Ze względu na centralną rolę w przesyłaniu komunikatów często obsługuje dane krytyczne, kolejki zadań, zdarzenia biznesowe oraz mechanizmy wymiany informacji pomiędzy zaufanymi usługami.

W takim modelu nawet pozornie ograniczona luka w autoryzacji może mieć duże znaczenie operacyjne. Naruszenie uprawnień w warstwie zarządzania albo wyciek metadanych infrastrukturalnych może otworzyć drogę do rekonesansu, eskalacji uprawnień i zakłócenia działania zależnych systemów.

Opisane podatności mają szczególne znaczenie dla środowisk chmurowych i współdzielonych, gdzie panel zarządzania lub API management bywa dostępne z sieci o podwyższonym ryzyku. Ryzyko rośnie dodatkowo wtedy, gdy organizacja korzysta z OAuth 2 do obsługi procesów administracyjnych lub integracji z zewnętrznym dostawcą tożsamości.

Analiza techniczna

CVE-2026-57219 to podatność o wysokim wpływie, związana z przestarzałym endpointem GET /api/auth. W określonych konfiguracjach endpoint ten może ujawnić sekret klienta OAuth zapisany w ustawieniu management.oauth_client_secret. Główny problem polega na tym, że mechanizm autoryzacji dla tego interfejsu dopuszczał żądanie mimo obecności danych wrażliwych.

Jeżeli atakujący pozyska taki sekret, może wykorzystać go do uzyskania tokenu administracyjnego i przejęcia kontroli nad brokerem. W konsekwencji możliwy staje się dostęp do wiadomości, kolejek, użytkowników, konfiguracji oraz operacji administracyjnych, co w środowisku produkcyjnym oznacza realne ryzyko sabotażu, manipulacji ruchem komunikatów i trwałych zmian konfiguracyjnych.

Druga luka, CVE-2026-57221, wynika z niewłaściwej autoryzacji podczas pasywnej deklaracji kolejek i exchange’y. W efekcie dowolny uwierzytelniony użytkownik mający możliwość połączenia z danym virtual hostem może enumerować nazwy kolejek i exchange’y oraz odczytywać podstawowe statystyki, takie jak liczba wiadomości i liczba konsumentów, nawet jeśli formalnie nie powinien mieć dostępu do tych obiektów.

Choć nie jest to podatność prowadząca bezpośrednio do zdalnego wykonania kodu, stanowi klasyczny przykład naruszenia granic izolacji. Metadane infrastrukturalne mogą ujawniać architekturę aplikacji, zależności między usługami, harmonogramy przetwarzania i krytyczne procesy biznesowe, a tym samym wspierać kolejne etapy ataku.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko dotyczy wdrożeń, w których interfejs management RabbitMQ jest osiągalny z niezaufanej sieci lub internetu. W takim scenariuszu CVE-2026-57219 może umożliwić ujawnienie sekretu OAuth bez uprzedniego uwierzytelnienia, a następnie eskalację do poziomu administracyjnego.

Dla organizacji oznacza to ryzyko naruszenia poufności komunikatów, modyfikacji topologii brokera, usuwania zasobów, zakłócenia pracy kolejek i wpływu na ciągłość działania aplikacji zależnych od RabbitMQ. W przypadku środowisk krytycznych biznesowo skutki mogą obejmować zarówno przestój operacyjny, jak i naruszenie zgodności lub bezpieczeństwa danych.

CVE-2026-57221 jest szczególnie istotna dla architektur wielodzierżawczych. Choć sama nie daje pełnej kontroli nad brokerem, osłabia separację tenantów i może ułatwiać rozpoznanie infrastruktury, mapowanie procesów oraz planowanie dalszych działań ofensywnych. To problem zwłaszcza dla usług SaaS, platform integracyjnych oraz współdzielonych instancji RabbitMQ.

Rekomendacje

Priorytetem powinno być natychmiastowe przejście na poprawione wersje RabbitMQ: 4.3.0, 4.2.6, 4.1.11, 4.0.20 lub 3.13.15, zależnie od używanej linii produktowej. Organizacje powinny również sprawdzić, czy ich środowisko wykorzystuje OAuth 2 z ustawieniem management.oauth_client_secret, ponieważ to właśnie ten wariant jest kluczowy dla scenariusza ujawnienia sekretu.

Jeżeli interfejs zarządzający był dostępny z internetu lub z sieci o ograniczonym zaufaniu, należy potraktować sekret OAuth jako potencjalnie skompromitowany i przeprowadzić jego rotację. Warto także przeanalizować logi dostępu do management API, zdarzenia administracyjne oraz wykorzystanie tokenów powiązanych z panelem zarządzania.

  • zaktualizować RabbitMQ do wersji zawierającej poprawki,
  • ograniczyć dostęp do portu 15672 wyłącznie do zaufanych segmentów administracyjnych,
  • zweryfikować ekspozycję endpointów management i polityki autoryzacji,
  • monitorować próby enumeracji kolejek i exchange’y,
  • przeprowadzić rotację sekretów oraz tokenów integracyjnych, jeśli istnieje ryzyko ekspozycji,
  • przeanalizować model izolacji tenantów i unikać nadmiernego współdzielenia virtual hostów.

Podsumowanie

Nowe podatności w RabbitMQ pokazują, że nawet dojrzałe komponenty middleware mogą stać się punktem krytycznym dla bezpieczeństwa całej architektury. CVE-2026-57219 niesie ryzyko ujawnienia sekretu OAuth i przejęcia brokera, natomiast CVE-2026-57221 osłabia izolację między tenantami przez wyciek metadanych kolejek i exchange’y.

Dla zespołów bezpieczeństwa i administratorów najważniejsze działania to szybkie wdrożenie poprawek, ograniczenie ekspozycji interfejsu zarządzającego oraz weryfikacja modelu segmentacji i uprawnień. W środowiskach wielodzierżawczych szczególnego znaczenia nabiera również kontrola nad widocznością zasobów w ramach wspólnego virtual hosta.

Źródła