CVE-2026-59317

JsonKafkaHeaderMapper and DefaultKafkaHeaderMapper include java.net in their default trusted packages list. When these mappers are used — which is the default configuration for all @KafkaListener consumers — an external Kafka producer can inject a java.net.InetAddress type via the spring_json_header_types message header. Affected versions: Spring for Apache Kafka 4.1.0, 4.0.0-4.0.6, 3.0.0-3.3.16, 2.9.0-2.9.14, and 2.8.12 and earlier.

JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper matched type headers against trusted packages using a prefix check, meaning trusting any package implicitly trusts all its subpackages. Combined with Jackson's default bean deserialization, a producer can supply crafted header values that cause the consumer to deserialize arbitrary JDK types. Affected versions: 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.

Spring Kafka's retry topic infrastructure did not sufficiently validate user-controlled header values before acting on them. A producer could send a record with a crafted retry_topic-attempts header to supply an out-of-range attempt count and cause the retry topic router to misidentify where the message was in the retry sequence.

Spring for Apache Kafka versions 4.0.0-4.0.5, 3.3.0-3.3.15, 3.2.0-3.2.13, 2.9.0-2.9.13, and 2.8.0-2.8.11 allow a producer to grow the consumer's heap without bound by sending records with unique spring.kafka.serialization.selector header values, leading to GC thrash and OutOfMemoryError.

In Spring for Apache Kafka versions 3.0.9 and earlier and 2.9.10 and earlier, a possible deserialization attack vector exists, but only if unusual configuration is applied. An attacker would need to construct a malicious serialized object in one of the deserialization exception record headers.