Description

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. Spring for Apache Kafka 4.1.0 Spring for Apache Kafka 4.0.0 - 4.0.6 Spring for Apache Kafka 3.0.0 - 3.3.16 Spring for Apache Kafka 2.9.0 - 2.9.14 Spring for Apache Kafka 2.8.12 and earlier

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-27T20:17:57.797Z",
  "pubdate": "2026-08-27T20:17:57.797Z",
  "executiveSummary": "The DeadLetterPublishingRecovererFactory component within the Spring for Apache Kafka library is susceptible to a Denial of Service (DoS) vulnerability triggered by improper input validation.\nThe vulnerability stems from the direct instantiation of a BigInteger object using unvalidated raw byte data sourced from the 'retry_topic-original-timestamp' header of an inbound ConsumerRecord.\nBy supplying a specially crafted header value containing a massive array of bytes, an attacker can force the application to perform resource-intensive calculations, leading to excessive CPU consumption and potential memory exhaustion.\nThis flaw affects multiple versions of Spring for Apache Kafka, specifically 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.\nThe exploit does not require authentication to the Kafka broker, as the attacker can inject the malicious header into the message flow. Successful exploitation results in the unavailability of the affected Kafka consumer process, impacting the reliability and throughput of the messaging pipeline.",
  "technicalDetails": "The root cause of this vulnerability lies in the insecure deserialization logic within the DeadLetterPublishingRecovererFactory. When processing messages, the component attempts to extract the 'retry_topic-original-timestamp' header to facilitate recovery operations. The implementation retrieves the raw byte array directly from the Kafka record header and passes it to the BigInteger(byte[] val) constructor without performing any sanity checks on the length or structure of the data.\nThe Java BigInteger(byte[] val) constructor is designed to handle arbitrary-precision integers. When provided with an excessively large byte array, the constructor performs complex arithmetic operations that scale non-linearly with the input size. An attacker can leverage this by sending a Kafka record with a 'retry_topic-original-timestamp' header populated with a very large byte array (e.g., several megabytes).\nUpon receiving such a record, the DeadLetterPublishingRecovererFactory triggers the BigInteger instantiation. This forces the JVM to allocate significant memory and utilize the CPU to process the massive integer conversion. Because this operation occurs synchronously during the message processing loop, the consumer thread is effectively blocked while the calculation proceeds. By repeatedly sending these malicious records, an attacker can saturate the consumer's resources, leading to thread starvation and effectively halting the processing of legitimate Kafka messages.\nThe attack flow is as follows: 1) The attacker constructs a malicious Kafka record, injecting a large byte array into the 'retry_topic-original-timestamp' header. 2) The record is produced to a Kafka topic that the vulnerable Spring application consumes. 3) The DeadLetterPublishingRecovererFactory component retrieves the record and reads the untrusted header bytes. 4) The library passes the raw, unvalidated bytes to the BigInteger constructor. 5) The JVM undergoes high CPU and memory usage to convert the large byte array into a BigInteger. 6) The consumer process becomes unresponsive, resulting in a Denial of Service for that specific consumer instance. This vulnerability is particularly dangerous because it bypasses standard input validation layers, operating directly at the protocol/deserialization level of the messaging framework."
}