CVE-2026-59275

Wersje Spring AMQP przed 1.5.5 zawierają podatność w klasie org.springframework.core.serializer.DefaultDeserializer, która umożliwia zdalnym atakującym wykonanie dowolnego kodu.

Gdy skonfigurowany jest ErrorHandler na poziomie kontenera (środek łagodzący dla znaleziska 221000), każde dostarczenie, którego przetwarzanie zgłasza błąd, trwale zużywa jeden kredyt linku. Po osiągnięciu initialCredits (domyślnie 100) nieudanych wiadomości kredyt odbiorcy spada do zera i broker przestaje dostarczać, pozostawiając słuchacza cicho zablokowanego, podczas gdy isRunning() nadal zwraca true. Podatność dotyczy Spring AMQP 4.1.0.

Aplikacje wysyłające logi do RabbitMQ przez TLS za pomocą appenderów Log4j2, polegające na udokumentowanym domyślnym ustawieniu, są narażone na atak man-in-the-middle, który może przechwycić każde zdarzenie logowania. Dotyczy to Spring AMQP w wersjach 4.1.0, 4.0.0-4.0.4, 3.2.0-3.2.12 oraz 2.4.18 i wcześniejszych.

Gdy kontrola aliveness zarządzania RabbitMQ zakończy się niepowodzeniem, skonfigurowane hasło administratora jest osadzone w postaci zwykłego tekstu w komunikacie wyjątku. Podatność dotyczy Spring AMQP w wersjach 4.1.0, 4.0.0-4.0.4, 3.2.0-3.2.12 oraz 2.4.18 i wcześniejszych.

Atakujący, który może publikować wiadomości do kolejki konsumowanej przez aplikację z włączoną dekompresją wiadomości, może doprowadzić do awarii JVM konsumenta pojedynczą wiadomością o rozmiarze około 1 MB. Dotyczy Spring AMQP 4.1.0, 4.0.0-4.0.4, 3.2.0-3.2.12 oraz 2.4.18 i wcześniejszych.

W Spring AMQP, aplikacje konfigurujące połączenie z brokerem przez RabbitConnectionFactoryBean.setUri("amqps://...") bez wywołania setUseSSL(true) otrzymują szyfrowanie TLS bez walidacji certyfikatu i weryfikacji nazwy hosta.

Podatność w Spring AMQP powoduje, że identyfikatory korelacji dla odpowiedzi w metodzie RabbitTemplate.sendAndReceive() z ustaloną kolejką odpowiedzi są przewidywalne z powodu wewnętrznego prostego licznika. Dotyczy wersji Spring AMQP 4.0.0-4.0.3, 3.2.0-3.2.10, 3.1.0-3.1.15 oraz 2.4.0-2.4.17.