CVE-2026-111496

Overview

Apache Kafka is an open-source distributed event streaming platform used for high-throughput, fault-tolerant data pipelines and stream processing. It stores records in partitioned, replicated, append-only logs on a cluster of brokers, and exposes producer, consumer, admin, Streams, and Connect APIs for publishing, subscribing to, and processing those records. The Java client and server components are published as Maven artifacts under org.apache.kafka.

A denial of service vulnerability (CVE-2026-111496) has been identified in the stream-time punctuation scheduler of Kafka Streams, which allows attackers who can write to a source topic to stall a Streams application's processing thread with a single record. Because the record stays in the topic, the stall returns each time the application restarts.

Per OWASP: The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed.

This issue affects multiple versions of Apache Kafka.

Details

Module Info

• Product: Apache Kafka
• Affected packages: org.apache.kafka:kafka-streams
• Affected versions: >=1.1.0 <=4.1.2, >=4.2.0 <=4.2.1, >=4.3.0 <=4.3.1
• GitHub repository: https://github.com/apache/kafka
• Published packages: https://central.sonatype.com/artifact/org.apache.kafka/kafka-streams
• Package manager: Gradle
• Fixed in:
  • OSS Apache Kafka 4.2.2, 4.3.2, 4.4.0
  • NES for Apache Kafka v3.1.5

Vulnerability Info

This Low-severity vulnerability is found in the org.apache.kafka:kafka-streams package in multiple versions of Apache Kafka. Kafka Streams derives its stream time from record timestamps. When stream time passes a scheduled STREAM_TIME punctuation, PunctuationSchedule.next() computes the next punctuation time with plain long arithmetic and no overflow check:

public PunctuationSchedule next(final long currTimestamp) {
    long nextPunctuationTime = timestamp + interval;
    if (currTimestamp >= nextPunctuationTime) {
        final long intervalsMissed = (currTimestamp - timestamp) / interval;
        nextPunctuationTime = timestamp + (intervalsMissed + 1) * interval;
    }
    ...
}

A record with a timestamp at or near Long.MAX_VALUE advances stream time to that value, so the computed next punctuation time wraps around to a negative number. PunctuationQueue.mayPunctuate() then puts the rescheduled punctuation back on the queue unconditionally and keeps looping while the head of the queue is due:

synchronized (pq) {
    boolean punctuated = false;
    PunctuationSchedule top = pq.peek();
    while (top != null && top.timestamp <= timestamp) {
        final PunctuationSchedule sched = top;
        pq.poll();
        if (!sched.isCancelled()) {
            processorNodePunctuator.punctuate(sched.node(), timestamp, type, sched.punctuator());
            if (!sched.isCancelled()) {
                pq.add(sched.next(timestamp));
            }
            punctuated = true;
        }
        top = pq.peek();
    }
    return punctuated;
}

The negative time is always less than or equal to the current stream time, so the loop never exits. It runs the punctuator over and over while holding the queue lock, and the StreamThread stops processing records. An application whose partitions are all affected becomes unresponsive; the brokers and the cluster are not affected. Triggering the flaw requires write access to a source topic whose topology uses stream-time punctuation, and a broker that stores the record. Brokers from Apache Kafka 4.0.0 reject such a timestamp by default through log.message.timestamp.after.max.ms, so the flaw is reachable on older brokers or where that bound has been relaxed.

Mitigation

Only recent versions of Apache Kafka are community-supported. Older lines are End-of-Life and will not receive public updates to address this issue. The Apache Kafka project does bugfix releases only for the last three minor releases; see the project's time-based release plan.

Users of the affected components should apply one of the following mitigations:

• Upgrade Apache Kafka to a currently supported release that contains the fix, such as 4.2.2.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• Mike Read (finder)