CVE-2026-111073

Interfejs API PushTelemetry po stronie brokera (KIP-714) sprawdza przed dekompresją tylko skompresowany rozmiar ładunku metryk klienta w oparciu o telemetry.max.bytes (domyślnie 1 MB). ClientTelemetryUtils.decompress() następnie dekompresuje ładunek bez ograniczenia rozmiaru zdekompresowanego pliku wyjściowego, zwiększając bufor sterty do momentu wyczerpania skompresowanych danych wejściowych. Mały, wysoce skompresowany ładunek (na przykład zera skompresowane za pomocą programu gzip) może zatem rozszerzyć się do setek megabajtów sterty brokera.


Wpływ:


Uwierzytelniony klient może wysłać żądanie PushTelemetry z małym, skompresowanym ładunkiem, który jest dekompresowany do bardzo dużego rozmiaru, zużywając stertę brokera nieproporcjonalnie do rozmiaru żądania. Powtarzające się lub równoczesne żądania mogą wyczerpać stertę brokera i spowodować błąd OutOfMemoryError, powodujący pogorszenie lub awarię brokera. klient skierowany do wielu brokerów może mieć wpływ na dostępność klastra. Funkcja PushTelemetry jest dostępna dla każdego uwierzytelnionego klienta i nie jest bramkowana przez listę ACL.


Łagodzenie:


Uaktualnij do Apache Kafka 4.2.2, 4.3.1 lub 4.4.0. W wersjach, których to dotyczy, nie ma konfiguracji, która w pełni uniemożliwia wzmocnienie, ponieważ telemetry.max.bytes ogranicza tylko skompresowany rozmiar; zmniejszenie wartości telemetry.max.bytes proporcjonalnie zmniejsza rozmiar po dekompresji w najgorszym przypadku i stanowi częściowe rozwiązanie łagodzące.


Rozdzielczość:


- Z Apache Kafka 4.2.2, 4.3.1 i 4.4.0: ClientTelemetryUtils.decompress() wymusza maksymalny rozmiar po dekompresji równy telemetry.max.bytes (domyślnie 1 MB). Dekompresja odczytuje ograniczone fragmenty i przerywa z wyjątkiem TelemetryTooLargeException, gdy suma dekompresji przekroczy limit, więc zbyt duży lub wysoce ściśliwy ładunek jest odrzucany zamiast być w pełni rozwijany na stercie. Dlatego zdekompresowany rozmiar jest domyślnie ograniczony.