CVE-2026-59278

DeadLetterPublishingRecovererFactory reads the retry_topic-original-timestamp header from an inbound ConsumerRecord and passes its raw bytes directly to new BigInteger(header.value()) with no length or format validation. Affects Spring for Apache Kafka versions 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.