---
id: "CVE-2026-111496"
kind: "vulnerability"
aliases: ["CVE-2026-111496"]
title: "Kafka Streams: a far-future record timestamp hangs stream threads indefinitely"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["data-pipelines", "java", "kafka", "kafka-streams", "package"]
not_affected_if: ["default-broker-timestamp-bound", "no-stream-time-punctuation"]
published_at: "2026-10-28T17:17:39+00:00"
first_seen_at: "2026-10-28T17:34:08+00:00"
updated_at: "2026-10-28T17:35:10+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111496", "first_seen_at": "2026-10-28T17:34:08+00:00"}]
---

# Kafka Streams: a far-future record timestamp hangs stream threads indefinitely

Kafka 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, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `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.
- Check whether the Streams topology uses stream-time punctuation (`context.schedule` with `PunctuationType.STREAM_TIME`).
- Check whether brokers accept far-future timestamps: look for `log.message.timestamp.after.max.ms` on source-topic brokers; brokers from Apache Kafka 4.0.0 reject them by default.

## Fix

- Upgrade Kafka Streams to `4.2.2`, `4.3.2`, or `4.4.0`.
- Keep `log.message.timestamp.after.max.ms` bounded on source topics (default one hour on 4.0.0+ brokers).
- Restrict write access to source topics.

## Timeline

- 2026-10-28T17:34:08+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-111496

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_