Live › vulnerability › CVE-2026-111496
Go to dashboardKafka Streams computes the next stream-time punctuation without an overflow check, so a record with a timestamp near Long.MAX_VALUE makes the punctuation time overflow negative. The queue then loops on that time while holding a lock, stalling the affected StreamThread, and the hang returns on restart because the record stays in the topic.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 17:34 UTC. All times on this page are UTC.
Only Kafka Streams applications are affected, not the brokers or the cluster. Exposure requires a topology that uses stream-time punctuation and a source topic that a writer can reach and where the broker stores far-future timestamps, which is the case on older brokers or where the one-hour bound has been relaxed. Applications without stream-time punctuation, or on brokers that reject such timestamps, are less exposed.
No product ranges from the sources yet.
kafka-streams-application-reset or check the Kafka Streams client version in your build file; affected versions are before 4.2.2, 4.3.2, and 4.4.0 on their respective lines.context.schedule with PunctuationType.STREAM_TIME).log.message.timestamp.after.max.ms on source-topic brokers; brokers from Apache Kafka 4.0.0 reject them by default.4.2.2, 4.3.2, or 4.4.0.log.message.timestamp.after.max.ms bounded on source topics (default one hour on 4.0.0+ brokers).Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-111496")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.