CVE-2026-111496: Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation
Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next() computed the next punctuation time as timestamp + (intervalsMissed + 1) interval with no overflow check. A record with a timestamp at or near Long.MAXVALUE advances stream time to that value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.
Impact:
A single record is enough. The affected StreamThread stops processing, and because the record stays in the topic the hang returns on restart; an application whose partitions are all affected becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster. Triggering it needs 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 (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers or where that bound has been relaxed.
Mitigation:
Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with overflow-checked arithmetic (clamped to Long.MAXVALUE), and a rescheduled punctuation is re-queued only when its time moves forward.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Kafka Streamsto a version that resolves this vulnerability.Fixed in 4.4.0 - Configuration
Keep log.message.timestamp.after.max.ms bounded on source topics.
Apache Kafka broker log.message.timestamp.after.max.ms = bounded - Compensating control
Restrict write access to the source topics.
Event History
Frequently Asked Questions
Are Kafka brokers or the Kafka cluster affected by this issue?
No. The impact is limited to the Kafka Streams application: an affected StreamThread can stop processing, and an application can become unresponsive if all of its partitions are affected.
What must an attacker be able to do to trigger the hang?
They need write access to a source topic used by a topology that performs stream-time punctuation. The broker must also accept and store a record with a timestamp at or near Long.MAX_VALUE.
Does the default broker configuration prevent exploitation?
Apache Kafka brokers from 4.0.0 reject these timestamps by default through log.message.timestamp.after.max.ms, set to one hour. The issue remains reachable on older brokers or where that limit has been relaxed.
Why can the problem return after restarting the Streams application?
The triggering record remains in the topic, so processing it again causes the StreamThread to hang again. Remediation therefore needs to account for the retained offending record as well as upgrading the Streams application.
Which Kafka Streams versions contain the fix?
Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0.