CVE-2023-34040
MediumCVSS 5.3Exploitation Probability (EPSS)
High risk80th percentile - higher than 80% of all known CVEs
Summary
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.
Risk Assessment
The organization is exposed to attacks that could lead to the execution of malicious code if appropriate security measures are not taken. In particular, the risk increases when the user allows untrusted sources to publish to a Kafka topic.
Recommendation
It is recommended to configure an ErrorHandlingDeserializer for the key and/or value of the record and to set the container properties checkDeserExWhenKeyNull and checkDeserExWhenValueNull to false. Additionally, publishing should be restricted to trusted sources.
Other vulnerabilities in Spring for Apache Kafka
See all- CVE-2026-59317Medium
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.
- CVE-2026-59278Medium
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.
- CVE-2026-41731High
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.
- CVE-2026-41727Medium
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.
- CVE-2026-41726Medium
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.
Original NVD description (English source)
In Spring for Apache Kafka 3.0.9 and earlier and versions 2.9.10 and earlier, a possible deserialization attack vector existed, but only if unusual configuration was applied. An attacker would have to construct a malicious serialized object in one of the deserialization exception record headers. Specifically, an application is vulnerable when all of the following are true: * The user does not configure an ErrorHandlingDeserializer for the key and/or value of the record * The user explicitly sets container properties checkDeserExWhenKeyNull and/or checkDeserExWhenValueNull container properties to true. * The user allows untrusted sources to publish to a Kafka topic By default, these properties are false, and the container only attempts to deserialize the headers if an ErrorHandlingDeserializer is configured. The ErrorHandlingDeserializer prevents the vulnerability by removing any such malicious headers before processing the record.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS