Spring Kafka Deserialization and Validation Flaws

Unsafe deserialization in Spring for Apache Kafka (versions 2.8.0-4.0.5 across multiple branches) allows a malicious Kafka producer to send crafted message headers that cause downstream consumers to instantiate arbitrary JDK types via Jackson. The flaw stems from a prefix-based trusted-packages check in JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper, which silently extends trust to every subpackage. No public exploit identified at time of analysis, but the bug class (CWE-502 with Jackson default typing) has a long history of leading to remote code execution in Spring/Java ecosystems.

Improper input validation in Spring for Apache Kafka's non-blocking retry topic infrastructure allows an authenticated network producer to disrupt message processing availability across multiple major version lines. By injecting a crafted `retry_topic-attempts` header with an out-of-range integer value, an attacker causes the retry topic router to misidentify the message's position in the retry sequence, producing high availability impact (A:H per CVSS). Affected deployments span Spring for Apache Kafka 2.8.x through 4.0.x. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis.

Unbounded heap growth in Spring for Apache Kafka's DelegatingDeserializer allows an authenticated network producer to trigger a Denial of Service against any consumer application that opts into this deserializer. By flooding the consumer with Kafka records carrying unique, randomized spring.kafka.serialization.selector header values, an attacker forces unbounded cache growth on the consumer's JVM heap, ultimately inducing GC thrash and OutOfMemoryError. No public exploit identified at time of analysis, and this is not listed in the CISA KEV catalog, but the low-complexity, network-accessible attack surface warrants prompt remediation for affected deployments.