CVE-2026-59317

JsonKafkaHeaderMapper i DefaultKafkaHeaderMapper zawierają java.net na liście domyślnych zaufanych pakietów. Gdy te mappery są używane (co jest domyślną konfiguracją dla wszystkich konsumentów @KafkaListener), zewnętrzny producent Kafka może wstrzyknąć typ java.net.InetAddress przez nagłówek wiadomości spring_json_header_types. Podatność dotyczy Spring for Apache Kafka w wersjach 4.1.0, 4.0.0-4.0.6, 3.0.0-3.3.16, 2.9.0-2.9.14 oraz 2.8.12 i wcześniejszych.

JsonKafkaHeaderMapper i przestarzały DefaultKafkaHeaderMapper dopasowują nagłówki typów do zaufanych pakietów za pomocą sprawdzania prefiksu, co oznacza, że zaufanie dowolnemu pakietowi niejawnie ufa wszystkim jego podpakietom. W połączeniu z domyślną deserializacją beanów Jacksona, producent może dostarczyć spreparowane wartości nagłówków, które powodują deserializację dowolnych typów JDK przez konsumenta. Dotyczy Spring for Apache Kafka 4.0.0-4.0.5, 3.3.0-3.3.15, 3.2.0-3.2.13, 2.9.0-2.9.13, 2.8.0-2.8.11.

Infrastruktura tematów ponownych prób Spring Kafka nie walidowała wystarczająco wartości nagłówków kontrolowanych przez użytkownika przed działaniem na nich. Producent mógł wysłać rekord z spreparowanym nagłówkiem retry_topic-attempts, aby podać nieprawidłową liczbę prób i spowodować błędną identyfikację pozycji wiadomości w sekwencji ponownych prób przez router tematów ponownych prób.

Spring for Apache Kafka w wersjach 4.0.0-4.0.5, 3.3.0-3.3.15, 3.2.0-3.2.13, 2.9.0-2.9.13 i 2.8.0-2.8.11 pozwala producentowi na nieograniczone zwiększanie sterty konsumenta poprzez wysyłanie rekordów z unikalnymi wartościami nagłówka spring.kafka.serialization.selector, co prowadzi do przeciążenia GC i błędu OutOfMemoryError.

W Spring dla Apache Kafka w wersjach 3.0.9 i wcześniejszych oraz 2.9.10 i wcześniejszych istnieje potencjalna podatność na atak deserializacji, która występuje tylko w przypadku nietypowej konfiguracji. Atakujący musiałby skonstruować złośliwy obiekt serializowany w jednym z nagłówków rekordów wyjątków deserializacji.