Apache Kafka up to 4.1.2/4.2.1/4.3.1 Streams PunctuationSchedule.next infinite loop

Summaryinfo

A vulnerability marked as critical has been reported in Apache Kafka up to 4.1.2/4.2.1/4.3.1. The impacted element is the function PunctuationSchedule.next of the component Streams. Performing a manipulation results in infinite loop. This vulnerability is identified as CVE-2026-111496. The attack can be initiated remotely. There is not any exploit available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in Apache Kafka up to 4.1.2/4.2.1/4.3.1. This affects the function PunctuationSchedule.next of the component Streams. The manipulation with an unknown input leads to a infinite loop vulnerability. CWE is classifying the issue as CWE-835. The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. This is going to have an impact on availability. The summary by CVE is:

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.

The advisory is shared at kafka.apache.org. This vulnerability is uniquely identified as CVE-2026-111496 since 10/16/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/28/2026). MITRE ATT&CK project uses the attack technique T1499 for this issue.

Upgrading to version 4.2.2, 4.3.2 or 4.4.0 eliminates this vulnerability.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Vendor

• Apache

Name

• Kafka

Version

• 4.1.0
• 4.1.1
• 4.1.2
• 4.2.0
• 4.2.1
• 4.3.0
• 4.3.1

License

• open-source

Website

• Vendor: https://www.apache.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion