CVE-2026-111496
KritikTeknik Veri (Otomatik)
- CVSS Skoru
- 9.1
- EPSS
- 0.2%
- CWE
- CWE-190
- KEV Durumu
- Hayır
Yayım tarihi: 28 Ekim 2026
Kafka Streams, akış zamanı saatini kayıt zaman damgalarından alır. PunctuationSchedule.next(), sonraki noktalama zamanını zaman damgası + (kaçırmış_aralıklar + 1) * aralık olarak hesaplar, ancak taşma kontrolü yapılmaz. Long.MAX_VALUE değerine yakın bir zaman damgasına sahip bir kayıt, akış zamanını bu değere ilerletir, böylece sonraki akış-zamanı noktalama negatif bir zamana taşar. PunctuationQueue sonra bu zamanı yeniden sıraya alır ve kilit tutarak sonsuz döngüye girer, böylece StreamThread'i durdurur. Etki: Tek bir kayıt yeterlidir. Etkilenen StreamThread işleme durur ve kayıt konuya kalacağı için duraklama yeniden başlatma üzerine geri döner; tüm bölümleri etkilenen bir uygulama yanıt veremez duruma gelir. Sadece Streams uygulaması etkilenir, broker'lar veya küme değil. Tetiklenmesi, akış-zamanı noktalama kullanan bir topolojinin kaynak konuya yazma erişimi gerektirir ve kaydı depolayan bir broker gerekir: Apache Kafka 4.0.0'dan itibaren broker'lar böyle bir zaman damgasını varsayılan olarak reddeder (log.message.timestamp.after.max.ms, bir saat), böylece yalnızca daha eski broker'larda veya bu sınırın esnetildiği yerlerde erişilebilir. Mitiğe: Kafka Streams'i 4.2.2, 4.3.2 veya 4.4.0 sürümüne yükseltin. Derinlik savunması olarak, kaynak konularda log.message.timestamp.after.max.ms sınırını korur ve bunlara yazma erişimi kısıtlayın. Çözüm: Apache Kafka 4.2.2, 4.3.2 ve 4.4.0'dan itibaren: sonraki noktalama zamanı taşma kontrollü aritmetikle hesaplanır (Long.MAX_VALUE'ye sabitlenir) ve yeniden planlanan bir noktalama, zamanı ileriye gittiğinde yeniden sıraya alınır.
Orijinal açıklama (İngilizce)
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.
Referanslar
Bu CVE için henüz editoryal inceleme yapılmadı. Sadece otomatik teknik veri gösteriliyor.