{"api_version":"1","generated_at":"2026-10-28T20:53:31+00:00","cve":"CVE-2026-111496","urls":{"html":"https://cve.report/CVE-2026-111496","api":"https://cve.report/api/cve/CVE-2026-111496.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-111496","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-111496"},"summary":{"title":"Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation","description":"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.\n\n\nImpact:\n\nA 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.\n\n\nMitigation:\n\nUpgrade 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.\n\n\nResolution:\n\nFrom 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.","state":"PUBLISHED","assigner":"apache","published_at":"2026-10-28 17:17:39","updated_at":"2026-10-28 20:17:18"},"problem_types":["CWE-190","CWE-835","CWE-190 CWE-190 Integer overflow or wraparound","CWE-835 CWE-835 Loop with unreachable exit condition ('infinite loop')"],"metrics":[],"references":[{"url":"https://kafka.apache.org/cve-list","name":"https://kafka.apache.org/cve-list","refsource":"security@apache.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"http://www.openwall.com/lists/oss-security/2026/10/28/14","name":"http://www.openwall.com/lists/oss-security/2026/10/28/14","refsource":"af854a3a-2127-422b-91ae-364da2661108","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-111496","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-111496","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache Kafka","version":"affected 1.1.0 4.1.2 semver","platforms":[]},{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache Kafka","version":"affected 4.2.0 4.2.1 semver","platforms":[]},{"source":"CNA","vendor":"Apache Software Foundation","product":"Apache Kafka","version":"affected 4.3.0 4.3.1 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Mike Read (GitHub: Michael-JRead)","lang":"en"},{"source":"CNA","value":"Matthias J. Sax <matthias@confluent.io>","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"providerMetadata":{"dateUpdated":"2026-10-28T20:06:55.726Z","orgId":"af854a3a-2127-422b-91ae-364da2661108","shortName":"CVE"},"references":[{"url":"http://www.openwall.com/lists/oss-security/2026/10/28/14"}],"title":"CVE Program Container"}],"cna":{"affected":[{"collectionURL":"https://repo.maven.apache.org/maven2","defaultStatus":"unaffected","packageName":"org.apache.kafka:kafka-streams","packageURL":"pkg:maven/org.apache.kafka/kafka-streams","product":"Apache Kafka","vendor":"Apache Software Foundation","versions":[{"lessThanOrEqual":"4.1.2","status":"affected","version":"1.1.0","versionType":"semver"},{"lessThanOrEqual":"4.2.1","status":"affected","version":"4.2.0","versionType":"semver"},{"lessThanOrEqual":"4.3.1","status":"affected","version":"4.3.0","versionType":"semver"}]}],"credits":[{"lang":"en","type":"reporter","value":"Mike Read (GitHub: Michael-JRead)"},{"lang":"en","type":"remediation developer","value":"Matthias J. Sax <matthias@confluent.io>"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<div>Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next()&nbsp;<span>computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no&nbsp;</span><span>overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that&nbsp;</span><span>value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then&nbsp;</span><span>re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.</span></div><br><div>Impact:</div><div>A single record is enough. The affected StreamThread stops processing, and because the record&nbsp;<span>stays in the topic the hang returns on restart; an application whose partitions are all affected&nbsp;</span><span>becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster.&nbsp;</span><span>Triggering it needs write access to a source topic whose topology uses stream-time punctuation,&nbsp;</span><span>and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by&nbsp;</span><span>default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers&nbsp;</span><span>or where that bound has been relaxed.</span></div><br><div>Mitigation:</div><div>Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep&nbsp;<span>log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.</span></div><br><div>Resolution:</div><div>From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with&nbsp;<span>overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is&nbsp;</span><span>re-queued only when its time moves forward.</span></div>"}],"value":"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.\n\n\nImpact:\n\nA 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.\n\n\nMitigation:\n\nUpgrade 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.\n\n\nResolution:\n\nFrom 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."}],"metrics":[{"other":{"content":{"text":"low"},"type":"Textual description of severity"},"scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-190","description":"CWE-190 Integer overflow or wraparound","lang":"en","type":"CWE"}]},{"descriptions":[{"cweId":"CWE-835","description":"CWE-835 Loop with unreachable exit condition ('infinite loop')","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-28T16:45:08.114Z","orgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","shortName":"apache"},"references":[{"tags":["vendor-advisory"],"url":"https://kafka.apache.org/cve-list"}],"source":{"discovery":"EXTERNAL"},"title":"Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation","x_generator":{"engine":"Vulnogram 1.0.3"}}},"cveMetadata":{"assignerOrgId":"f0158376-9dc2-43b6-827c-5f631a4d8d09","assignerShortName":"apache","cveId":"CVE-2026-111496","datePublished":"2026-10-28T16:45:08.114Z","dateReserved":"2026-10-16T09:55:02.432Z","dateUpdated":"2026-10-28T20:06:55.726Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-28 17:17:39","lastModifiedDate":"2026-10-28 20:17:18","problem_types":["CWE-190","CWE-835","CWE-190 CWE-190 Integer overflow or wraparound","CWE-835 CWE-835 Loop with unreachable exit condition ('infinite loop')"],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"111496","Ordinal":"1","Title":"Apache Kafka: Kafka Streams StreamThread hang from integer overf","CVE":"CVE-2026-111496","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"111496","Ordinal":"1","NoteData":"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.\n\n\nImpact:\n\nA 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.\n\n\nMitigation:\n\nUpgrade 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.\n\n\nResolution:\n\nFrom 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.","Type":"Description","Title":"Apache Kafka: Kafka Streams StreamThread hang from integer overf"}]}}}