CVE-2026-111115
KritikTeknik Veri (Otomatik)
- CVSS Skoru
- 9.1
- EPSS
- 0.2%
- CWE
- —
- KEV Durumu
- Hayır
Yayım tarihi: 28 Ekim 2026
Apache Kafka'nın esnek protokol sürümleri için oluşturulan kodlu okuyucular, gönderenin beyan ettiği etiketli alan sayısını okuyarak her bilinmeyen alan için bir RawTaggedField nesnesini korur. Bu sayı, yalnızca dış istek çerçevesi boyutu (socket.request.max.bytes) ile sınırlıydı ve kalan arabellek baytları veya bir üst sınır ile karşılaştırılmadı. Her girişi en az iki bayt (bilinmeyen etiket 0, boyut 0) ile kodlanabildiği için, mütevazi bir istek on milyonlarca etiketli alan beyan edebilir ve her beyan edilen alan için bir nesne ayırma zorlayabilir. Esnek istek üstbilgileri (üstbilgi sürümü 2, esnek API'ler gibi ApiVersions v3 tarafından kullanılır) bu şekilde ayrıştırılır, böylece büyütme istek üstbilgisine kendiliğinden uygulanır. Etki: Esnek istek üstbilgisi, yetkilendirme, istek dağıtımı ve istek zamanı kota hesaplamasından önce ağ iş parçacığı üzerinde ayrıştırılır. Bir istemci, üstbilgisinde yaklaşık 20 milyon etiketli alan beyan eden birkaç on megabaytlık bir istek gönderebilir ve bu da broker yığınını tüketen veya tüm süreç genelinde GC duraklamalarına neden olan yaklaşık o kadar RawTaggedField ayırması zorlar ve broker hizmetini reddeder. Üstbilgi, ApiVersions (v3) gibi ön kimlik doğrulama API'leri için ayrıştırıldığından, ayırma kimlik doğrulamasından önce gerçekleşebilir; hiçbir Kafka kaynağı ACL veya kotası gerekmez. Mitiğasyon: Apache Kafka 4.2.2, 4.3.2 veya 4.4.0'a yükseltin. Buna kadar, socket.request.max.bytes'ı düşürmek ve broker dinleyicilerine ağ erişimini kısıtlamak maruz kalma durumunu azaltır, ancak completely kaldırmaz. Çözüm: Apache Kafka 4.2.2, 4.3.2 ve 4.4.0'dan itibaren: oluşturulan okuyucular, esnek sürümlü iletilerin etiketli alan sayısını, herhangi bir alan başına ayırma yapmadan önce, negatif bir sayı, kalan arabellek baytlarını aşan bir sayı veya sabit bir üst sınırı (10.000) aşan bir sayı reddederek sınırlar.
Orijinal açıklama (İngilizce)
Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself. Impact: The flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation.
Referanslar
Bu CVE için henüz editoryal inceleme yapılmadı. Sadece otomatik teknik veri gösteriliyor.