Apache Kafka Streams EUVD-2026-112171

Three concrete prerequisites must all hold: (1) the attacker has write/producer access to a source topic; (2) that topic feeds a Kafka Streams topology that schedules stream-time (not wall-clock) punctuation; and (3) a broker actually stores a record whose timestamp is at or near Long.MAX_VALUE. Condition (3) is the main limiter - Apache Kafka brokers from 4.0.0 reject timestamps more than one hour in the future by default via log.message.timestamp.after.max.ms, so the attack is only reachable against older brokers or deployments that have widened or disabled that bound. Impact is limited to availability of the Streams application; brokers and the broader cluster are unaffected. Authentication requirements are not confirmed from available data because no CVSS vector was provided, though the description states write access to a source topic is required.

No CVSS vector, EPSS score, KEV entry, or public PoC is present in the input, so quantitative exploitation signals are absent and cannot be compared against each other. The vuln.today decision label is 'monitor', the lowest urgency tier, which is consistent with an availability-only defect (CWE-190 integer overflow leading to an indefinite lock-holding loop) that affects a single Kafka Streams application rather than brokers or the cluster. Impact is a denial of service against the StreamThread, with no confidentiality or integrity effect. Exploitation is further gated: the attacker needs write access to a source topic whose topology uses stream-time punctuation, and the hostile timestamp must actually be stored by a broker - brokers from Apache Kafka 4.0.0 reject timestamps more than one hour in the future by default (log.message.timestamp.after.max.ms), so on default modern deployments the record never persists and the bug is not reachable. The realistic footprint is therefore older brokers, or deployments that relaxed that bound. Net assessment: this is a genuine but bounded availability issue - a real priority only for operators still on vulnerable Streams versions who also run older/relaxed brokers and expose write access to punctuation-using source topics; for everyone on default 4.0.0+ brokers the practical risk is low. No active exploitation is indicated, and no public exploit identified at time of analysis.

An actor with producer (write) rights to a source topic feeding a Kafka Streams topology that schedules stream-time punctuation sends a single record carrying a timestamp at or near Long.MAX_VALUE. Stream time advances to that value, the next punctuation time overflows to a negative number, and PunctuationQueue re-queues and loops on it indefinitely while holding a lock, hanging the StreamThread; because the poison record persists in the topic, the hang recurs on restart. No public exploit code is identified at time of analysis, and the record only takes effect if a broker stores the future timestamp (older or relaxed-config brokers).