Vulnerability Directory | CVE-2026-41727

Overview

Spring for Apache Kafka applies core Spring concepts to the development of Kafka-based messaging solutions, providing the KafkaTemplate, message-driven listener containers, and the non-blocking retry topic infrastructure that Spring and Spring Boot applications use to produce and consume Apache Kafka records.

A medium-severity vulnerability (CVE-2026-41727) has been identified in Spring for Apache Kafka. The retry topic feature coordinates non-blocking retries by attaching metadata headers to each record: retry_topic-attempts records how many delivery attempts have occurred, and retry_topic_backoff-timestamp tells the consumer when the record may next be processed. In affected versions, neither header is validated before being acted on. A producer who can send records to a topic the application consumes can forge an out-of-range attempt count to make the retry router misidentify where a message is in the retry sequence, or forge a far-future backoff timestamp to make the backoff manager pause the listener arbitrarily long, stalling consumption far beyond any intended retry window.

Per OWASP, a denial-of-service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed; there are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resource-handling vulnerabilities, among others.

This issue affects versions >=2.7.0 <=2.7.14, >=2.8.0 <=2.8.11, >=2.9.0 <=2.9.13, >=3.1.0 <=3.1.10, >=3.2.0 <=3.2.13, >=3.3.0 <=3.3.15, and >=4.0.0 <=4.0.5, as well as older, unsupported versions, of Spring for Apache Kafka.

‍

Details

Module Info

Product: Spring for Apache Kafka
Affected packages: spring-kafka
Affected versions: >=2.7.0 <=2.7.14, >=2.8.0 <=2.8.11, >=2.9.0 <=2.9.13, >=3.1.0 <=3.1.10, >=3.2.0 <=3.2.13, >=3.3.0 <=3.3.15, >=4.0.0 <=4.0.5
GitHub repository: https://github.com/spring-projects/spring-kafka
Published packages: https://central.sonatype.com/artifact/org.springframework.kafka/spring-kafka
Package manager: Maven
Fixed in:
NES for Spring for Apache Kafka 2.7.x, 2.8.x, 2.9.x, 3.1.x, 3.2.x
Spring for Apache Kafka 3.3.16, 4.0.6 (OSS)

Vulnerability Info

Applications that enable Spring for Apache Kafka's non-blocking retries, via @RetryableTopic or a RetryTopicConfiguration bean, route failed records through a chain of retry topics before a final dead-letter topic. The framework keeps track of the retry state in record headers that any producer can set, and two of those headers were trusted without validation.

The first flaw is in the attempt counter. When a record fails, DeadLetterPublishingRecovererFactory reads the retry_topic-attempts header to decide which retry topic (or the dead-letter topic) the record should be forwarded to next:‍

private int getAttempts(ConsumerRecord<?, ?> consumerRecord) {
    Header header = consumerRecord.headers().lastHeader(RetryTopicHeaders.DEFAULT_HEADER_ATTEMPTS);
    if (header != null) {
        byte[] value = header.value();
        if (value.length == Byte.BYTES) { // backwards compatibility
            return value[0];
        }
        else if (value.length == Integer.BYTES) {
            return ByteBuffer.wrap(value).getInt();
        }
        else {
            LOGGER.debug(() -> "Unexpected size for " + RetryTopicHeaders.DEFAULT_HEADER_ATTEMPTS + " header: "
                    + value.length);
        }
    }
    return 1;
}

‍

The decoded value is passed directly into destination topic resolution. A forged four-byte header can claim any attempt count, including negative values or Integer.MAX_VALUE, causing the router to misidentify the message's position in the retry sequence, for example sending a first-failure record straight past its remaining retries. The legacy one-byte path also sign-extends the raw byte, so a value of 0x80 decodes as -128 rather than 128, corrupting the count even for non-malicious producers that wrote large legitimate values.

The second flaw is in the backoff timestamp. Before dispatching a record from a retry topic, KafkaBackoffAwareMessageListenerAdapter reads the retry_topic_backoff-timestamp header and, if present, asks the backoff manager to pause the consumer until that time arrives:

private Optional<Long> maybeGetBackoffTimestamp(ConsumerRecord<K, V> data) {
    return Optional
            .ofNullable(data.headers().lastHeader(this.backoffTimestampHeader))
            .map(timestampHeader -> new BigInteger(timestampHeader.value()).longValue());
}

‍No bounds check is applied to the decoded timestamp. A producer who writes a far-future value, up to Long.MAX_VALUE, instructs the backoff manager to suspend the listener's partition for an effectively unbounded duration, halting consumption of that topic and turning a single crafted record into a denial of service.

The remediation hardens both decoding paths: the attempts header is read as unsigned in the legacy one-byte form and clamped to a sane range, with out-of-range values and unexpected header lengths resolving to an attempt count of 1, and backoff timestamps whose implied pause would exceed one day are ignored as if the header were absent, so the record proceeds to the listener without invoking the backoff manager. Only applications that use the retry topic feature process these headers.

This vulnerability was introduced in 2021 with Spring for Apache Kafka 2.7.

‍

Mitigation

Spring for Apache Kafka 3.3.x and 4.0.x receive the fix in the open-source releases 3.3.16 and 4.0.6; the 2.8.x, 2.9.x, and 3.2.x lines, along with older lines such as 2.7.x and 3.1.x, are past their open-source support window and have no publicly available fix. Users still running an affected open-source line that no longer receives free updates should not attempt to hand-patch the retry topic header handling.

To remediate this issue, affected users have two recommended options:

Upgrade to a supported, fixed release of Spring for Apache Kafka (3.3.16 or 4.0.6).
Adopt HeroDevs Never-Ending Support (NES) for Spring for Apache Kafka, which provides a drop-in compatible build with this vulnerability fixed for release lines that are otherwise end-of-life, with no code changes required. Learn more about HeroDevs Never-Ending Support for Spring and request coverage at https://www.herodevs.com/support/spring-nes.

‍