Critical CWE-835 CVEs

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2026-111496	Critical	2026-10-28	No exploit published	No public exploit	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.MAX_VALUE 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.MAX_VALUE), and a rescheduled punctuation is re-queued only when its time moves forward.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2026-111496

Critical

2026-10-28

No exploit published

No public exploit

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.MAX_VALUE 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.MAX_VALUE), and a rescheduled punctuation is re-queued only when its time moves forward.