CVE-2026-114349
Niskie ryzyko· EPSS 16%Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 16 - wyżej niż 16% wszystkich znanych CVE
Streszczenie
Podatność w Apache Kafka pozwala uwierzytelnionemu producentowi z prawem zapisu do tematu na zadeklarowanie w skompresowanym rekordzie rozmiaru ciała do około 2 GiB, co powoduje próbę alokacji bufora i błąd OutOfMemoryError. Może to doprowadzić do zatrzymania wątków obsługi żądań brokera, konsumentów, a w przypadku wątku log-cleaner do trwałego zatrzymania kompakcji logów na brokerze.
Ocena ryzyka
Atakujący z uprawnieniami zapisu może wywołać odmowę usługi (crash brokera lub zatrzymanie kompakcji logów), co wpływa wyłącznie na dostępność, bez ujawnienia lub modyfikacji danych. W konfiguracji z -XX:+ExitOnOutOfMemoryError pojedyncze żądanie może zakończyć proces JVM brokera.
Rekomendacja
Zaktualizuj Apache Kafka do wersji 4.2.2, 4.3.2 lub 4.4.0 oraz ustaw parametr max.decompressed.message.bytes na ograniczoną wartość odpowiednią dla obciążenia (domyślnie jest praktycznie nieograniczony). Do czasu aktualizacji ogranicz prawo zapisu do zaufanych producentów, ponieważ limity rozmiaru żądań i kwoty nie mitigują problemu.
Inne podatności w Apache Kafka
Zobacz wszystkie- CVE-2026-33557Krytyczne
W Apache Kafka domyślna klasa walidatora JWT (`DefaultJwtValidator`) akceptuje dowolne tokeny JWT bez weryfikacji podpisu, wystawcy ani odbiorcy. Atakujący może wygenerować token z dowolnego wystawcy z dowolną nazwą użytkownika, a broker go zaakceptuje.
- CVE-2026-83525Niskie ryzyko· EPSS 8%
Nieprawidłowy operator (CWE-480) w obsłudze RPC FetchSnapshot w Apache Kafka w wersjach od 2.8.0 przed 4.2.2 oraz od 4.3.0 przed 4.3.2 pozwala uwierzytelnionemu atakującemu z uprawnieniem CLUSTER_ACTION na wywołanie odmowy usługi. Wykorzystanie następuje poprzez spreparowane żądanie FetchSnapshotRequest z pustą tablicą tematów lub tematem bez partycji, co powoduje zakończenie procesu kontrolera.
- CVE-2026-112375Niskie ryzyko· EPSS 13%
Uwierzytelniony podmiot (principal) Kafki bez żadnych uprawnień autoryzacyjnych może zmusić brokera do odczytania pliku lub zmiennej środowiskowej z hosta brokera i zwrócenia ich zawartości. Żądanie IncrementalAlterConfigs lub AlterConfigs skierowane na zasób BROKER trafia do walidacji konfiguracji przed sprawdzeniem autoryzacji, a rozwiązywanie zmiennych konfiguracyjnych (${file:...}, ${env:...}) omija listę dozwolonych dostawców konfiguracji wprowadzoną jako mitygacja CVE-2024-31141.
- CVE-2026-111551Niskie ryzyko· EPSS 13%
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.
- CVE-2026-111115Niskie ryzyko· EPSS 15%
Podatność w Apache Kafka dotyczy czytników generowanych dla elastycznych wersji protokołu, które odczytują liczbę pól tagowanych zadeklarowaną przez nadawcę i tworzą obiekt RawTaggedField dla każdego nieznanego pola. Liczba ta nie była ograniczona rozmiarem bufora ani stałym limitem, co pozwala na amplifikację — niewielkie żądanie może zadeklarować dziesiątki milionów pól i wymusić tyle samo alokacji obiektów, wyczerpując stertę brokera lub powodując pauzy GC. Nagłówek elastycznego żądania jest parsowany przed autoryzacją, więc atak może nastąpić przed uwierzytelnieniem, bez wymaganych ACL ani limitów.
- CVE-2026-111108Niskie ryzyko· EPSS 19%
Podatność w Apache Kafka polega na tym, że generowane czytniki protokołu wstępnie alokują kolekcję na podstawie liczby elementów zadeklarowanej przez nadawcę, sprawdzanej tylko względem pozostałych bajtów bufora (zakładając ok. 1 bajt na element). Dla tablic z kluczem czytnik alokuje kolekcję o pojemności (2 * liczba + 1), więc żądanie o rozmiarze kilkudziesięciu MB może wymusić alokację sterty wielokrotnie większą, zanim odczytany zostanie jakikolwiek element. Problem dotyczy wszystkich typów API Kafki z polem tablicowym.
- CVE-2026-111073Niskie ryzyko· EPSS 10%
Podatność w brokerze Apache Kafka dotyczy API PushTelemetry (KIP-714), które waliduje jedynie rozmiar skompresowanego ładunku metryk względem telemetry.max.bytes, a następnie dekompresuje go bez limitu rozmiaru wyjściowego. Mały, silnie kompresowalny ładunek może rozrosnąć się do setek megabajtów sterty brokera, powodując OutOfMemoryError.
- CVE-2026-110985Niskie ryzyko· EPSS 2%
W brokerze Apache Kafka używającym SASL/OAUTHBEARER z domyślnym walidatorem (DefaultJwtValidator), gdy parametr sasl.oauthbearer.jwks.endpoint.url nie jest ustawiony i nie dostarczono własnego resolvera kluczy, walidator po cichu przełącza się na ClientJwtValidator, który nie weryfikuje podpisu, algorytmu ani wystawcy JWT. Broker uruchamia się bez ostrzeżenia, akceptując każdy poprawny strukturalnie token, w tym tokeny z "alg":"none". Jest to pozostałość po CVE-2026-33557, którego poprawka przywróciła weryfikację podpisu tylko na ścieżce z ustawionym URL JWKS.
- CVE-2026-110952Niskie ryzyko· EPSS 2%
Broker Apache Kafka uwierzytelniający klientów przez SASL/OAUTHBEARER z walidatorem JWKS domyślnie weryfikuje podpis JWT, ale nie sprawdza roszczeń iss i aud, jeśli nie ustawiono opcji sasl.oauthbearer.expected.issuer i sasl.oauthbearer.expected.audience. W rezultacie token podpisany prawidłowo, ale wydany przez innego wystawcę lub bez roszczenia aud, może zostać zaakceptowany. Ryzyko dotyczy głównie środowisk z wielodostępnym JWKS lub współdzielonymi kluczami podpisującymi.
- CVE-2026-41115Średnie
W Apache Kafka zidentyfikowano podatność nieprawidłowej autoryzacji w implementacji API CONSUMER_GROUP_DESCRIBE (69). API to waliduje operację DESCRIBE na zasobie GROUP zamiast operacji READ, co jest udokumentowane w oficjalnej dokumentacji i KIP-848. Może to prowadzić do błędnie skonfigurowanych list ACL i niezamierzonych postaw bezpieczeństwa.
Oryginalny opis (angielski, źródło NVD)
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.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS