CVE-2026-61634
NieznaneCVSS 0.0Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 23 - wyżej niż 23% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Złośliwy broker może zakłócić działanie aplikacji korzystających z klienta RabbitMQ Java, prowadząc do niedostępności usług.
Rekomendacja
Zaleca się aktualizację biblioteki RabbitMQ Java client do wersji 5.33.0 lub nowszej.
Inne podatności w RabbitMQ Java client
Zobacz wszystkie- CVE-2026-69220Wysokie
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.
- CVE-2026-69219Wysokie
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.
- CVE-2026-63337Wysokie
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.
- CVE-2026-63336Średnie
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.
- CVE-2026-63335Średnie
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.
Oryginalny opis (angielski, źródło NVD)
The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.33.0, the AMQP connection tuning path records the negotiated AMQP frame_max value, but src/main/java/com/rabbitmq/client/impl/SocketFrameHandler.java and NettyFrameHandlerFactory continue to validate broker-controlled frame payload lengths against maxInboundMessageBodySize because the negotiated limit is not applied consistently through setMaxInboundFramePayloadSize. A malicious or compromised broker can send a method frame larger than the negotiated frame_max during or after connection establishment, causing the client to allocate and decode a protocol-invalid frame instead of rejecting it with MalformedFrameException. The protocol violation can disrupt the affected connection and cause client-side denial of service. This issue is fixed in version 5.33.0.