CVE-2026-75516
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 44 - wyżej niż 44% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może spowodować wyczerpanie pamięci procesu klienta, co prowadzi do awarii aplikacji i potencjalnie do przerwania działania usług zależnych od RabbitMQ.
Rekomendacja
Zaleca się natychmiastową aktualizację biblioteki klienckiej RabbitMQ Java do wersji 5.34.0 lub nowszej, aby zapobiec atakom DoS przez nadmierną alokację pamięci.
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.
- CVE-2026-61634Nieznane
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.
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.34.0, AMQConnection.start() applies Math.min(maxInboundMessageBodySize, frameMax) after Connection.Tune negotiation even though AMQP defines frameMax value zero as unlimited and ConnectionFactory.DEFAULT_FRAME_MAX is zero. When the client default and server-negotiated value are both zero, the result is passed to Utils.framePayloadLimit(int), which interprets zero as Integer.MAX_VALUE and disables the configured maxInboundMessageBodySize cap. A malicious AMQP server, or a man-in-the-middle attacker able to modify Connection.Tune and inject frames into the connection, can then send an oversized frame of any frame type, causing Frame.readFrom() to allocate a large byte array before content-level validation and potentially terminate the client process through memory exhaustion. This issue is fixed in version 5.34.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS