Katalog CVE

CVE-2026-111551

Niskie ryzyko· EPSS 13%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.22%

Percentyl 13 - wyżej niż 13% wszystkich znanych CVE

Streszczenie

W kilku ścieżkach deserializacji Apache Kafka pole rozmiaru lub liczby elementów jest odczytywane z danych wejściowych i używane bezpośrednio do alokacji tablicy, kolekcji lub bufora bajtów, bez sprawdzenia dostępnych danych. Mały spreparowany rekord może zadeklarować bardzo duży rozmiar i wymusić alokację wielu gigabajtów, powodując OutOfMemoryError. Dotyczy to m.in. ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata i AssignmentInfo w Kafka Streams oraz ListDeserializer w bibliotece klienta.

Ocena ryzyka

Atakujący może doprowadzić do wyczerpania pamięci i awarii wątku Kafka Streams lub konsumenta, a ponieważ spreparowany rekord pozostaje w temacie, błąd może powtarzać się po restarcie. Broker i pozostała część klastra nie są zagrożone, ale dostępność aplikacji konsumujących dane może zostać zakłócona.

Rekomendacja

Zaktualizuj Apache Kafka do wersji 4.2.2, 4.3.2 lub 4.4.0, które walidują deklarowany rozmiar względem pozostałych danych wejściowych. Dodatkowo, jeśli autoryzacja jest włączona, ogranicz zapis do wewnętrznych tematów aplikacji i grup konsumenckich oraz produkcję do tematów konsumowanych przez ListSerde wyłącznie do zaufanych podmiotów.

Inne podatności w Apache Kafka

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde). Impact: An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS