Odebrany

CVE-2026-114349

opublikowano: 28.10.2026, 18:17

modyfikacja: 28.10.2026, 21:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

Gdy broker dekoduje skompresowaną partię rekordów, dekoder poszczególnych rekordów odczytuje zadeklarowany rozmiar treści ze zdekompresowanego strumienia i przydziela bufor o tym rozmiarze przed sprawdzeniem go pod kątem dostępnych bajtów lub dowolnego skonfigurowanego limitu. Rozmiar jest kontrolowany przez osobę atakującą, a wsadowe CRC go nie ogranicza, więc małe (około 90-bajtowe) skompresowane żądanie utworzenia z poprawnością CRC może zadeklarować rozmiar treści do około 2 GiB i zmusić brokera do podjęcia próby tej alokacji, wywołując OutOfMemoryError. Limit rozmiaru rekordu (maks. wiadomość w bajtach), limit rozmiaru żądania i limity klienta/brokera ograniczają tylko rozmiar skompresowanego przewodu, a nie zadeklarowany rozmiar po zdekompresowaniu.

Wpływ:

Uwierzytelniony podmiot zabezpieczeń z opcją Write on the topic może powodować awarię wątków obsługi żądań brokera (osiąganych, gdy kodek partii różni się od kompresji.type tematu i rekordy są ponownie kodowane) oraz dowolnego konsumenta pobierającego rekord, odmawiając usługi. W przypadku brokerów rozpoczynających się od opcji -XX:+ExitOnOutOfMemoryError, co jest częstym utrudnieniem, pojedyncze spreparowane żądanie kończy maszynę JVM brokera. A co ważniejsze, spreparowany rekord jest akceptowany podczas przetwarzania i zapisywany na dysku; gdy moduł czyszczący dzienniki później odczyta go w skompaktowanym temacie, błąd OutOfMemoryError (błąd, a nie wyjątek) kończy wątek czyszczący, który nie jest uruchamiany ponownie. Przy domyślnym pojedynczym wątku czyszczącym zagęszczanie logów zostaje zatrzymane dla całego brokera, łącznie z wewnętrznymi tematami __consumer_offsets i __transaction_state, a stan utrzymuje się po ponownym uruchomieniu do czasu usunięcia naruszającego rekordu. Wpływ dotyczy wyłącznie dostępności; żadne dane nie są ujawniane ani zmieniane.

Łagodzenie:

Uaktualnij do Apache Kafka 4.2.2, 4.3.2 lub 4.4.0 i ustaw wartość max.decompressed.message.bytes (na poziomie brokera i/lub tematu) na ograniczoną wartość odpowiednią dla Twojego obciążenia. Sama aktualizacja nie wystarczy: w celu zapewnienia zgodności wstecznej ta konfiguracja domyślnie przyjmuje faktycznie nieograniczoną wartość (około 2 GiB), więc broker pozostaje odsłonięty do czasu ustawienia limitu. Wybierz wartość równą lub nieco wyższą od największego legalnego zdekompresowanego rekordu generowanego przez aplikacje i wygodnie poniżej sterty brokera podzielonej przez liczbę wątków obsługi żądań i wątków czyszczących. Dopóki nie uaktualnisz i nie skonfigurujesz limitu, ogranicz dostęp do zapisu do zaufanych producentów; przydziały i max.message.bytes nie łagodzą tego problemu.

Rozdzielczość:

Od wersji Apache Kafka 4.2.2, 4.3.2 i 4.4.0: broker sprawdza zadeklarowany rozmiar zdekompresowanej treści rekordu w oparciu o max.decompressed.message.bytes przed alokacją w ścieżkach sprawdzania poprawności produktu, kompresowania dziennika i wyszukiwania sygnatury czasowej oraz odrzuca rozmiary nadmierne lub ujemne za pomocą wyjątku InvalidRecordException. Operatorzy muszą ustawić tę konfigurację na ograniczoną wartość, aby była chroniona, ponieważ jej wartość domyślna jest faktycznie nieograniczona.

When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size.

Impact:

An authenticated principal with Write on a topic can crash broker request-handler threads (reached when a batch's codec differs from the topic's compression.type and records are re-encoded) and any consumer that fetches the record, denying service. On brokers started with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the broker JVM. More seriously, a crafted record is accepted at ingest and written to disk; when the log-cleaner later reads it on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner thread, which is not restarted. With the default of a single cleaner thread, log compaction then stops for the entire broker, including the internal __consumer_offsets and __transaction_state topics, and the condition persists across restarts until the offending record is removed. The impact is availability only; no data is disclosed or altered.

Mitigation:

Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is not sufficient: for backward compatibility this configuration defaults to an effectively unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a value at or slightly above the largest legitimate decompressed record your applications produce, and comfortably below the broker heap divided by the number of request-handler and cleaner threads. Until you can upgrade and configure the limit, restrict Write access to trusted producers; quotas and max.message.bytes do not mitigate this issue.

Resolution:

From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record's declared decompressed body size against max.decompressed.message.bytes before allocating, on the produce-validation, log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with InvalidRecordException. Operators must set this configuration to a bounded value to be protected, as its default is effectively unlimited.

>_ Słabości (CWE)

CWE-400 CWE-789 CWE-1284

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve