CVE-2026-106121

Biblioteka klienta RabbitMQ dla Javy przed wersją 5.35.0 umieszcza surowy URI w komunikatach wyjątków, gdy parsowanie URI AMQP się nie powiedzie. Ponieważ URI może zawierać nazwę użytkownika i hasło w postaci jawnej, dane uwierzytelniające brokera mogą wyciec do logów startowych, systemów monitoringu, logów CI czy kopiowanych stack trace'ów.

Biblioteka klienta RabbitMQ dla Javy przed wersją 5.36.0 niepoprawnie dekoduje uszkodzone bajty UTF-8 w ValueReader.readShortstr, zamieniając je na znaki zastępcze, które po ponownym zakodowaniu przekraczają limit AMQP shortstr. Atakujący może wysłać wiadomość RPC z uszkodzoną właściwością, powodując nieobsłużony wyjątek przed potwierdzeniem i wielokrotne przetwarzanie tej samej wiadomości, co prowadzi do wyłączenia konsumentów.

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.34.0, AMQConnection.start() stosuje Math.min(maxInboundMessageBodySize, frameMax) po negocjacji Connection.Tune, mimo że AMQP definiuje wartość frameMax zero jako nieograniczoną, a ConnectionFactory.DEFAULT_FRAME_MAX wynosi zero. Gdy wartość domyślna klienta i wartość negocjowana z serwerem są obie zerowe, wynik jest przekazywany do Utils.framePayloadLimit(int), który interpretuje zero jako Integer.MAX_VALUE i wyłącza skonfigurowany limit maxInboundMessageBodySize. Złośliwy serwer AMQP lub atakujący man-in-the-middle zdolny do modyfikacji Connection.Tune i wstrzykiwania ramek do połączenia może następnie wysłać zbyt dużą ramkę dowolnego typu, powodując, że Frame.readFrom() alokuje dużą tablicę bajtów przed walidacją na poziomie treści i potencjalnie kończy proces klienta przez wyczerpanie pamięci. Problem został naprawiony w wersji 5.34.0.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.1 pozwala na rekurencyjne wywołania ValueReader.readFieldValue dla typów AMQP F i A bez limitu głębokości zagnieżdżenia. Złośliwy serwer AMQP lub pośrednik sieciowy może wysłać około 580 zagnieżdżonych poziomów tabel w ramce connection.start przed uwierzytelnieniem, co powoduje StackOverflowError i zatrzymanie wątku przetwarzania wejścia, prowadząc do odmowy usługi.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.1 używa ValueReader.readBytes do akceptowania zadeklarowanej długości poniżej Integer.MAX_VALUE i alokuje tablicę bajtów przed sprawdzeniem dostępnych bajtów w ramce. Złośliwy peer AMQP może wysłać pole LongString z typem S i długością taką jak 0x7FFFFFFE, powodując alokację około 2 GB i OutOfMemoryError, co może zakończyć działanie JVM i spowodować odmowę usługi.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.0 przekazuje wartość javaReturnType z niezaufanej odpowiedzi system.describe do Class.forName z inicjalizacją. Atakujący, który może odpowiedzieć na żądanie JsonRpcClient przez wspólny broker lub przechwycenie sieci, może wybrać klasę już obecną w JVM ofiary i wywołać jej statyczny inicjalizator, co może wpłynąć na poufność, integralność i dostępność procesu klienta.

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.33.0, metody com.rabbitmq.client.ConnectionFactory.useSslProtocol() i ConnectionFactory.useSslProtocol(String) konfigurują com.rabbitmq.client.TrustEverythingTrustManager i pozostawiają wyłączoną weryfikację nazwy hosta, co powoduje akceptowanie dowolnych certyfikatów serwera, w tym certyfikatów samopodpisanych. Atakujący sieciowy, który może przechwycić połączenie TLS, może podszyć się pod brokera RabbitMQ, czytać chroniony ruch AMQP i modyfikować ruch bez weryfikacji certyfikatu lub nazwy hosta. Poprawka zmienia produkcyjne pomocnicze funkcje TLS, aby używały domyślnego magazynu zaufania JVM i włącza weryfikację nazwy hosta, zachowując jawnie nazwany pomocniczy tryb deweloperski bez weryfikacji. Problem został naprawiony w wersji 5.33.0.

Biblioteka kliencka RabbitMQ Java umożliwia aplikacjom Java i JVM łączenie się i interakcję z węzłami RabbitMQ. Przed wersją 5.31.0, przychodzące składanie poleceń AMQP w src/main/java/com/rabbitmq/client/impl/CommandAssembler.java przetwarza metodę zawierającą treść i nagłówek, którego wartość remainingBodyBytes jest mniejsza niż następujący po niej payload AMQP.FRAME_BODY. CommandAssembler.consumeBodyFrame odejmuje kontrolowaną przez peera długość payloadu przed walidacją, że pasuje, co powoduje, że remainingBodyBytes staje się ujemne i zgłasza surowy wyjątek UnsupportedOperationException zamiast MalformedFrameException. Złośliwy lub skompromitowany broker może wysłać tę nieprawidłową sekwencję na otwartym niezerowym kanale, aby zakończyć przetwarzanie ramek i zamknąć połączenie klienta, powodując odmowę usługi dla pracy korzystającej z tego połączenia. Problem został naprawiony w wersji 5.31.0.

Biblioteka kliencka RabbitMQ Java przed wersją 5.33.0 nie stosuje spójnie negocjowanego limitu frame_max podczas walidacji rozmiaru ramek od brokera. Złośliwy broker może wysłać ramkę większą niż dozwolona, co prowadzi do alokacji i dekodowania nieprawidłowej ramki zamiast jej odrzucenia, powodując przerwanie połączenia i odmowę usługi po stronie klienta.