CVE-2026-63337

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 klienta RabbitMQ dla Javy przed wersją 5.37.0 zawiera błąd w com.rabbitmq.tools.json.JSONReader.read(), który nie kończy pracy, gdy dane wejściowe kończą się wewnątrz łańcucha znaków lub komentarza liniowego. Parser domyślnie używany przez DefaultJsonRpcMapper może w takiej sytuacji wyczerpać stertę lub bez końca zużywać CPU, powodując odmowę usługi.

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